[d-kernel] [RFC] strict BuildRequires for kernel patches

[Evgeny Sinelnikov]

В сообщении от Воскресенье 10 Июль 2005 23:01 Sergey Vlasov написал(a):
> 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 не будет пересобираться).

- либо действительно сохранять набор патчей для всех поддерживаемых ядер, 
а не только веток. Насколько я понимаю механизм указывающий на принадлежность 
патчей в {feat,fix}-пакетах веткам:
%source 01      2.4.x.patch                      2.4
%source 51      2.6.x.patch                      2.6
несложно расширить до указания принадлежности ядру:
%source 01      2.4.x.patch                      2.4
%source 21      2.4.27.patch                    2.4.27
%source 31      2.4.29.patch                    2.4.29
%source 51      2.6.x.patch                      2.6
%source 61      2.6.10.patch                    2.6.10
Это решение даёт возможность сборки некоторого набора текущих поддерживаемых 
версий ядер на одних и тех же {feat,fix}-пакетах. При этом не отменяется 
текущая схема ведения патчей по веткам. В этом случае вместо выбрасывания  
патча ветки (2.6, например), устаревшего для последней версии ядра, он будет 
перенесён список прямо указывающий на ядра с которыми он можем быть собран 
(2.6.9, 2.6.10). Кроме того такой подход позволит обеспечить возможность 
введения патчей "с четвёртой цифрой", которые сразу должны указывать на 
версию ядра, а не ветки и не будут смешаны в общую кучу исправлений.

> > Может еще для ядра, которое пошло в сизиф,  где-нибудь сохранять набор
> > патчей, с которыми оно было собрано?
>
> Версии патчей, использованные при сборке, сейчас пишутся в
> %description; старые версии патчей можно вытащить из kernel CVS (за
> исключением нескольких пакетов, собирающихся "левым" образом).
> Естественно, чтобы собрать в hasher именно старое ядро, нужно
> использовать соответствующий старый репозиторий (в частности, не
> содержащий более новых пакетов kernel-{fix,feat}-* - иначе при сборке
> будут использованы новые версии).

По моему, этот способ не удобен, тем более не представляю себе возможным вести 
на таком репозитории реальной работы, требующей не только старого набора 
патчей. Например, текущая стабильная (тестовая) версия RTAI (aka vesuvio - 
3.1r2) не собирается на ядрах выше 2.6.10. При этом достаточно не удобно 
брать (а самое главное следить за актуальностью)  старых версий fix-патчей из 
kernel CVS с текущими.

> > Или собирать пакет, в котором будет содержимое
> > hasher/chroot/usr/src/kernel/patches/. Можно будет собрать такое же
> > ядро.
>
> Каким образом - руками?
>
> > > 2) Использование при сборке ядра слишком новых пакетов с патчами также
> > > может привести к возникновению неприятных проблем.  Патчи для новой
> > > версии ядра довольно часто подходят и к старым версиям, но в новых
> > > пакетах kernel-fix-* могут быть удалены патчи, которые были нужны для
> > > старых версий ядра - в результате ядро, собранное по какой-то причине
> > > с таким новым kernel-fix-*, не будет содержать нужных исправлений.
> > >
> > > Для предотвращения таких ситуаций можно явно объявлять версии ядер, к
> > > которым подходят патчи, например, добавив в пакеты с патчами Provides
> > > вида kernel-fix-core(2.4.29), kernel-fix-core(2.6.12).  При переходе
[skip]

Возможно вариант, предложенный выше, даст более гибкое решение, чем макросы: 
%supported_kernel_versions и %require_patches_for_version. Хотя такие макросы 
могли бы дать формализацию, упомянутого выше списка поддерживаемых ядер, на 
уровне зависимостей. В любом случае такого рода жесткие зависимости будут 
полезны.

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

Они сейчас уже распилены внутри соответствующих пакетов (см. выше). Или это 
другое? Уже сейчас, насколько я понимаю, по kversion из kernel-image на этапе 
сборки можно вычленить нужный набор 2.4 и 2.6 патчей из kernel-{fix,feat}. 
Повторюсь. Если расширить этот выбор по возможности указания конкретной 
версии ядра, то это не будет ли решением проблемы?

-- 
Sin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.altlinux.ru/pipermail/devel-kernel/attachments/20050711/259709bd/attachment.bin