From: Sergey Vlasov <vsu@altlinux.ru> To: ALT Linux Kernel Development <devel-kernel@altlinux.ru> Cc: Alex Yustasov <yust@anti-leasure.ru> Subject: Re: [d-kernel] [RFC] strict BuildRequires for kernel patches Date: Sun, 10 Jul 2005 23:01:17 +0400 Message-ID: <20050710190117.GB13412@procyon.home> (raw) In-Reply-To: <20050710181043.GA28373@yust.work> [-- Attachment #1: Type: text/plain, Size: 3055 bytes --] On Sun, Jul 10, 2005 at 09:10:43PM +0300, Alex Yustasov wrote: > On Sun, Jul 10, 2005 at 08:55:51PM +0400, Sergey Vlasov wrote: > > Я вишу два варианта борьбы с этим безобразием: > > > > - либо явно прописывать в spec-файлах ядер используемые версии пакетов > > с патчами (неудобно); > > > > - либо брать текущие версии пакетов с патчами на момент сборки пакета > > с ядром (предполагая, что мантейнер соберёт ядро с правильными > > патчами, а после этого src.rpm не будет пересобираться). > Может еще для ядра, которое пошло в сизиф, где-нибудь сохранять набор > патчей, с которыми оно было собрано? Версии патчей, использованные при сборке, сейчас пишутся в %description; старые версии патчей можно вытащить из kernel CVS (за исключением нескольких пакетов, собирающихся "левым" образом). Естественно, чтобы собрать в hasher именно старое ядро, нужно использовать соответствующий старый репозиторий (в частности, не содержащий более новых пакетов kernel-{fix,feat}-* - иначе при сборке будут использованы новые версии). > Или собирать пакет, в котором будет содержимое > hasher/chroot/usr/src/kernel/patches/. Можно будет собрать такое же > ядро. Каким образом - руками? > > 2) Использование при сборке ядра слишком новых пакетов с патчами также > > может привести к возникновению неприятных проблем. Патчи для новой > > версии ядра довольно часто подходят и к старым версиям, но в новых > > пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для > > старых версий ядра - в результате ядро, собранное по какой-то причине > > с таким новым kernel-fix-*, не будет содержать нужных исправлений. > > > > Для предотвращения таких ситуаций можно явно объявлять версии ядер, к > > которым подходят патчи, например, добавив в пакеты с патчами Provides > > вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12). При переходе > Может kernel-fix-core(2.6.12-altN)? Тогда уж kernel-fix-core(2.6.12-std26-altN). Но это получится опять-таки явное прописывание версий всех патчей, только не в spec-файле kernel-image-*, а по всем использованным пакетам с патчами. Кроме того, пропадает возможность собрать свой вариант ядра на базе имеющихся kernel-{fix,feat}-*, не трогая эти пакеты. Кстати, устаревшие пакеты kernel-image-* можно обнаружить при автоматической пересборке, даже если до действительной несобираемости дело ещё не дошло - по несовпадению исходного и пересобранного src.rpm (сейчас отличается только %description, в случае автоматического проставления зависимостей на пакеты с патчами будут ещё и различия в BuildRequires). Хотя будет множество ложных срабатываний (например, все пакеты с ядрами 2.4.x будут объявлены устаревшими после обновления ядер 2.6.x, поскольку многие пакеты с патчами для этих ядер общие). Так что такую проверку ввести не получится (ну разве что где-нибудь выкладывать результаты для информации, но без рассылки спама). Или же придётся распилить пакеты с патчами на отдельные для 2.4 и 2.6 (но сколько же тогда будет этих пакетов...). [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-07-10 19:01 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-07-10 16:55 Sergey Vlasov 2005-07-10 17:06 ` [d-kernel] " Konstantin A. Lepikhov 2005-07-10 18:10 ` [d-kernel] " Alex Yustasov 2005-07-10 19:01 ` Sergey Vlasov [this message] 2005-07-10 22:24 ` Evgeny Sinelnikov 2005-07-11 9:41 ` Alex Yustasov 2005-07-11 9:13 ` Michael Shigorin 2005-07-10 18:19 ` [d-kernel] А давайте ещё Anton D. Kachalov 2005-07-10 19:12 ` Sergey Vlasov 2005-07-11 9:12 ` [d-kernel] kernel arch Michael Shigorin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050710190117.GB13412@procyon.home \ --to=vsu@altlinux.ru \ --cc=devel-kernel@altlinux.ru \ --cc=yust@anti-leasure.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git