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 (но
сколько же тогда будет этих пакетов...).