[d-kernel] [RFC] strict BuildRequires for kernel patches
Sergey Vlasov
vsu на altlinux.ru
Вс Июл 10 20:55:51 MSD 2005
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
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя : отсутствует
Тип : application/pgp-signature
Размер : 189 байтов
Описание: отсутствует
Url : http://lists.altlinux.ru/pipermail/devel-kernel/attachments/20050710/aed5bf3f/attachment.bin
Подробная информация о списке рассылки devel-kernel