From: Sergey Vlasov <vsu@altlinux.ru> To: ALT Linux Kernel Development <devel-kernel@altlinux.ru> Subject: [d-kernel] [RFC] strict BuildRequires for kernel patches Date: Sun, 10 Jul 2005 20:55:51 +0400 Message-ID: <20050710165551.GA13412@procyon.home> (raw) [-- Attachment #1: Type: text/plain, Size: 6023 bytes --] Hello! В текущей схеме сборки ядер имеются следующие проблемы: 1) В сборочных зависимостях пакетов kernel-image-* не указываются конкретные версии пакетов с патчами (kernel-fix-*, kernel-feat-*). Из-за этого возможна сборка пакета ядра с устаревшими версиями патчей. Это, кстати, уже произошло как минимум один раз: =========================================================================== $ diff <(rpm -qip /raid/ALT/archive/Sisyphus/2005/06/30/files/SRPMS/kernel-image-std26-up*) <(rpm -qip /raid/ALT/archive/Sisyphus/2005/06/30/files/i586/RPMS/kernel-image-std26-up*) 3,6c3,6 < Release : alt11 Build Date: Tue Jun 14 00:33:46 2005 < Install date: (not installed) Build Host: vsu.hasher.altlinux.org < Group : System/Kernel and hardware Source RPM: (none) < Size : 199090 License: GPL --- > Release : alt11 Build Date: Tue Jun 14 17:17:25 2005 > Install date: (not installed) Build Host: bee5.hasher.altlinux.org > Group : System/Kernel and hardware Source RPM: kernel-image-std26-up-2.6.11-alt11.src.rpm > Size : 36385402 License: GPL 26c26 < kernel-fix-core-2005.06.13-alt1 --- > kernel-fix-core-2005.05.13-alt1 28,29c28,29 < kernel-fix-fs-2005.06.13-alt1 < kernel-fix-net-2005.06.13-alt1 --- > kernel-fix-fs-2005.05.13-alt1 > kernel-fix-net-2005.05.13-alt1 31c31 < kernel-fix-drivers-char-2005.06.13-alt1 --- > kernel-fix-drivers-char-2005.03.14-alt1 39c39 < kernel-fix-drivers-media-2005.06.13-alt1 --- > kernel-fix-drivers-media-2005.05.10-alt1 =========================================================================== Я вишу два варианта борьбы с этим безобразием: - либо явно прописывать в spec-файлах ядер используемые версии пакетов с патчами (неудобно); - либо брать текущие версии пакетов с патчами на момент сборки пакета с ядром (предполагая, что мантейнер соберёт ядро с правильными патчами, а после этого src.rpm не будет пересобираться). Второй вариант может быть реализован, например, таким макросом: =========================================================================== %get_patch_requires %(for pkg in %get_patch_list; do \ rpmquery --dbpath '%_dbpath' --qf ' %%{NAME} >= %%|SERIAL?{%%{SERIAL}:}|%%{VERSION}-%%{RELEASE} ' --whatprovides "$pkg" 2>/dev/null || \ echo -n " $pkg "; \ done) =========================================================================== При этом в spec-файле ядра будет указываться: BuildRequires: %get_patch_requires (сейчас в этом месте используется %get_patch_list). Зависимости указываются с ">=", что вообще-то тоже не совсем правильно (если какой-то вариант ядра обновляется редко, результат его пересборки в текущем окружении может отличаться от изначальной сборки из-за обновления патчей), но если там написать "=", ядра будут крайне редко находиться в пересобираемом состоянии. 2) Использование при сборке ядра слишком новых пакетов с патчами также может привести к возникновению неприятных проблем. Патчи для новой версии ядра довольно часто подходят и к старым версиям, но в новых пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для старых версий ядра - в результате ядро, собранное по какой-то причине с таким новым kernel-fix-*, не будет содержать нужных исправлений. Для предотвращения таких ситуаций можно явно объявлять версии ядер, к которым подходят патчи, например, добавив в пакеты с патчами Provides вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12). При переходе на новую версию ядра необходимо будет обновить все необходимые для этого ядра пакеты с патчами, даже если старый патч без изменений подходит к новому ядру. Естественно, всё это должно быть завёрнуто в макросы: =========================================================================== %_required_kernel_version %nil %require_patches_for_version() %global _required_kernel_version (%1) %supported_kernel_versions() %(for ver in %*; do echo "Provides: %name($ver) = %version-%release"; done) %get_patch_requires %(for pkg in %get_patch_list; do \ rpmquery --dbpath '%_dbpath' --qf ' %%{NAME}%_required_kernel_version >= %%|SERIAL?{%%{SERIAL}:}|%%{VERSION}-%%{RELEASE} ' --whatprovides "$pkg%_required_kernel_version" 2>/dev/null || \ echo -n " $pkg%_required_kernel_version "; \ done) %format_patch_list %(for pkg in %get_patch_list; do \ rpmquery --dbpath '%_dbpath' --qf '\\n\\t%%{NAME}-%%|SERIAL?{%%{SERIAL}:}|%%{VERSION}-%%{RELEASE}' --whatprovides "$pkg%_required_kernel_version" 2>/dev/null || \ printf '\\n\\t%%s' "$pkg"; \ done) =========================================================================== При этом в пакетах kernel-fix-*, kernel-feat-* добавляются строки вида: %supported_kernel_versions 2.4.29 2.6.12 В пакеты kernel-image-* добавляется строка: %require_patches_for_version %kversion (эти зависимости нельзя включать по умолчанию, чтобы сохранилась возможность пересобирать с новым kernel-build-tools ядра для старых дистрибутивов). Однако возникает неприятная ситуация с пакетами kernel-feat-evms, kernel-feat-evms-nodm, kernel-feat-fs-squashfs - эти пакеты собираются не из kernel CVS, поэтому с их обновлением для введения нового Provides с очередной версией ядра будут проблемы. Что делать с такими пакетами, я пока не могу придумать (кроме ликвидации такого метода сборки и помещения всех пакетов kernel-{feat,fix}-* в kernel CVS). Какие будут мнения? Проблему 1 надо исправлять в любом случае, поскольку эти грабли один раз уже сработали. Проблема 2 пока теоретическая, но для редко обновляющихся вариантов ядер тоже может всплыть (кроме того, при введении таких зависимостей заброшенные kernel-image-* будут сразу становиться несобирающимися, если даже патчи по каким-то причинам не отвалятся). -- Sergey Vlasov [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2005-07-10 16:55 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-07-10 16:55 Sergey Vlasov [this message] 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 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=20050710165551.GA13412@procyon.home \ --to=vsu@altlinux.ru \ --cc=devel-kernel@altlinux.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