jeden wielki kernel.spec vs wiele kernel-*

[Jakub Bogusz]

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

[1] wprawdzie nie da się zrobić zależności = od części release, ale...
    da się od katalogu zawierającego w nazwie tę część - czyli do
    zrobienia. Chyba nawet wystarczyłyby zmiany wewnątrz już używanych
    makr.


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"...

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

- 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.

  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).

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


Tyle na razie - pod rozwagę.

-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/