jeden wielki kernel.spec vs wiele kernel-*

[Tomasz Kłoczko]

On Thu, 22 May 2003, Jakub Bogusz wrote:

> Jeszcze trochę się zastanawiałem nad $Subject i:
> 
> Jak na razie padła jedna większa wada obecnego rozwiązania: konieczność
> przebudowania wszystkich kernel-* przy zmianach w podstawowym kernelu.
> 
> Jeśli to jest/stanie się naprawdę dokuczliwe, to można to spróbować
> ograniczyć przez podzielenie podzielenie release na dwie części (np.
> major.minor), gdzie:
> - major byłoby używane w nazwie katalogu z modułami/plików vmlinuz
>   i initrd; tylko ta część występowałaby w %{_kernel_ver}
>   i w zależnościach kernel-*[1]; byłoby zmieniane przy naruszaniu
>   binarnej kompatybilności (w razie wątpliwości: przy dodawaniu nowej
>   funkcjonalności, wymianie podsystemów itp.), zmiana oznaczałaby
> - minor byłoby zmieniane przy poprawkach błędów oraz security nie
>   ingerujących w ABI

Przypominałoby mi to nieco jazdę na rowerze z kijkiem w ręce w taki sposób
że jedna reką trzymasz kierownicę, a drugą ręką machasz w sposób 
niekontrolowany w okolicach szprych koła :)
Nie dość że jedna ręka to mało do kierowania (tylko w jednym etapie byłoby
to spójne) to dodatkowo w międzyczaie przy machaniu kijem w okolicach
szprych mamy drugie zargożenie wywrotką i rozjechaniem spójnosci w 
sytaicji kiedy nagle by się zokazało że komuś coś nie chodzi, a już
mielibyśmy podzielony kernel wynikowy na grupu z modułami.

[..]
> Wady jednego wielkiego kernel.spec ze wszystkim zamiast kernel-*:
> - koszmarne prowadzenie takiej kobyły (już teraz jest to ciężkie...
>   ostatnio muszę trochę grzebać w 2.4.20 i coś o tym wiem)
>   łączenie wielu łat w mniej sprawiłoby tylko, że prowadzenie samych łat
>   stałoby się dodatkowym koszmarem.
> Czy są chętni do rozwijania tak zrobionego kernela? Żeby potem nie było
> "dlaczego nikt mi nie chce pomagać przy kernelu"...

Na razie nie czuję sie przekonany do tego choć widzę nie tylko negatywy 
tego podejścia.

Powód jest prosty. Wprowadzienie po kilka patchy do kolejnej wwersji 
kernela i zwiazne z tym komplikacje to pikuś w porówniu z potejcjalnie
rosnącym zbiorem kernl-* produkowancyh z poza kernel.spec.
I jedno i drugie jest pracochłonne. Zakładająć że przez najblizszy czas 
kerneli wychodzić będzie sporo koniczność przebudowywania wszytkich 
innych pakietów produkujących kernel-*, podbijania rel, pilnowanie 
etykietoniania (jeszcza na pewno przez jakis czas) dość słabo nastraja do 
optymistcznego podejcia tego. Wolę bawić się z jedna paczka źródłową.
O syndomie obecnego ra/u/s już nie wspomne.

> - konieczność przebudowania tej kobyły przy zmianie każdego składnika
>   (teraz wystarczy tylko _jeden_ _mały_ pakiet)

Jednej kobyły. Po pzrebudowaniu tejze kobyły nei musiosz pilnować momentu 
keidy mozęsz przenieść wszystkei kernel-* z ready do drzewka podstawowego. 
Jest tu spore zagrozenei że cos się jeszcze rozjedzie.

> - czas budowania (2.4.20-6 buduje się niecałe 1.5h na Athlonie 1GHz,
>   >5h na B50, niecałe 4h na Alphie 500MHz[2])
>   [2] no, po paru poprawkach... bodajże dwa patche kolidują i gcc 2.95
>   się sypie na 3 modułach; inna sprawa, że i tak pewnie alpha się
>   z tego nie zbootuje.

Z tego punktu widzenia mniej czasochłonne będzie budowanie wyłącznie z 
kernel.spec bo odpada przebudowywanie pakietów które nie produkują 
kernel-* w których ten kod to tylko okruch.

>   A m.in. czas budowania rozstrzyga, czy w przypadku potrzeby zbudowania
>   jądra różniącego się jakąś opcją czy patchem od dystrybucyjnego
>   chętniej zrobi się rpmbuild -bb && sudo rpm -i czy make bzImage
>   modules && sudo make modules_install (w uproszczeniu, ale wiadomo
>   o co chodzi).

Jeżeli ograniczy się ilość nakładanych patchy do kilku w sumie grupując w
jednym np. obsługę zupełnie nowych urządzeń, w drugim aktualizacje juz
obecnych driverów, a w trzecim poprawki błędów w międzyczaie zebrane
robienie takich zreczy w miedzyuczaie powinno być nawet prostrze.
Proste pytanie kóre dzisiaj zadałem Marcinowi ilustrujac co robi Wojtek:  
dlaczego wszytkie poprawki na symbole w modułach nie są w jednym patchu ?

> - dodatkowe utrudnienia dla używających jąder niedystrybucyjnych;
>   zwłaszcza w połączeniu z poprzednim.

Jeszcze jedno.
Przypomina mie się rozmowa z Pawłem. Jej ogólny sens:

P: e100/e1000 z kernela to śmieć, a ja potrzebuję czegoś porządnego,
T: dlaczego nie włączysz i nie przykryjesz tego śmiecia w kernelu ?
P: bo nie używam kernela dystrybucyjnego.
T: dlaczego nie używasz kernerla dystrybucyjnego ?
P: bo e100/e1000 z kernela to dla mnie śmieć, a ja potrzebuję czegoś 
   porządnego.

Do tego dochodzi to że w sumie e100/e1000 z binarnie budowancyh pakietów w 
tej konkretnej sytuacji to styrata czasu. Dlaczego ? Ano dlatego że 
Pawłe nie używając dysrybucyjnego kernela bieże poprostu src.rpm-a z e100 
i to sobie przebudowuje na własnym kernelu.
Po co mam się wysilać, pilnowac spójnosici itp/itd na ftp ? po to żeby 
ktoś tą robotę wysał jak cytrynę i nic nie zwrócił w zamian ? Więcej 
żądał jeszcze żebym robił wszystko żeby mógł mnie wyciskać dalej przy 
każdej kolejnej okazji (?).
Jak będą jakieś kłpoty z kernelem to nawet nie będzie możliwości
sporządznia wiarygodnego raportu w którym bedzie można w sposób 
na podstawie środowiska o znanych własnościach i żeby przy okazji otrzymać 
w zamian choćby wiarygodna informację że coś jest nie tak.

Kernel buduje sie długo. Buildery maja sporo każdej doby przestoju. 
Budowac się to może na razie swobodnie. Kernel to zasób budujacy się na
tyle długo że w międzyczasie można spokojnie opracować nawet coś średniej
wielkości.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*