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