2.2 vs 2.4 -- propozycja

[Paweł Sakowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ostatnio rozgrywa się dyskusja, którą wersję jądra wspierać jako
standardowe jądro PLD. Ponieważ są argumenty zarówno za 2.2 jak i 2.4,
wypadałoby rozwijać oba jądra równolegle (do czasu, kiedy wszyscy uznają
serię 2.4 za jedynie słuszną). Zatem proponuję, żeby na eftepie (w
/PLD-1.0/.../RPMS) leżały obie wersje jądra i pakiety pomocnicze dla
jednej i drugiej. O ile mi wiadomo, pakiety zależne od wersji jądra dzielą
się na:

1. moduły (alsa, ltmodem, ...)
2. narzędzia (firewall-init i okolice)

Ad.1: Tutaj jest też problem także z aktualizacją, kiedy zmienia się
wersja jądra. Dlatego proponuję w przypadku pakietów z modułami odejść od
standardowego nazewnictwa plików .rpm i stworzyć coś w stylu
alsa-driver-up-0.5.10b-1-2.2.19.i686.rpm (przy odpowiednim wsparciu ze
strony rpm'a). Do tego Conflicts: kernel != %{_kernel_ver}, żeby ktoś się
nie zagapił. Tu IMO branczowanie nie jest potrzebne, bo nawet jeśli są
jakieś różnice w budowaniu między 2.2 a 2.4, można to rozwiązać
odpowiednimi konstrukcjami shella w stylu if %{_kernel_ver}... (zrobiłem
tak w przypadku lirca).

Ad.2: Tu nie występuje zależność od SUBLEVELa, ale można zastosować
analogiczny mechanizm nazewnictwa: firewall-init-2.99.5-1-2.4.i686.rpm.
Różnice są tu dalej idące, niż w przypadku modułów, ale także dałoby się
uniknąć rozbranczowienia speców. Widziałbym to tak, że z CVSowego modułu
firewall-init do SOURCES wyeksportowałoby się oba brancze (z nazwami
np. %{name}-2.99.5-2.2.tar.gz i %{name}-2.99.5-2.4.tar.gz. Oba byłyby
wymienione w specu jako Source i wybór właściwego dokonywałby się na
podstawie %{_kernel_ver} (n.b. czy nie warto tego makra wrzucić do
macros.pld?). Innych narzędzi z rozbiciem wersji nie znam, ale można
zastosować analogiczny mechanizm.

Pozostaje jeszcze problem przebudowywania wszystkiego dla odpowiednich
wersji jądra (iptables dla 2.4, alsa-driver-up dla obu). Widziałbym to
tak: na górze speca dopisuje się:

# BUILD FOR 2.2
# BUILD FOR 2.4

i na builderach daje się coś takiego (z zastrzeżeniem, że nie mam pojęcia
jak działają nasze buildery):

if head -5 $SPECFILE|grep '^# BUILD FOR 2.2'>/dev/zero; then
	rm -f /usr/src/linux
	ln -s linux-2.2.19 /usr/src/linux
	do_build
	built=1
fi
if head -5 $SPECFILE|grep '^# BUILD FOR 2.4'>/dev/zero; then
	rm -f /usr/src/linux
	ln -s linux-2.4.5 /usr/src/linux
	do_build
	built=1
fi
[ -z "$built" ] && do_build

Oczywiście potrzeba, żeby na builderach leżały po dwa kernel-source i
kernel-headers, ale to chyba da się zrobić.

Koments?

+--------------------------------------------------------------------+
|   In God we trust. All others must   :            Paweł Sakowski   |
|  present a valid X.500 certificate.  :   <pawel w sakowski.eu.org>   |
+--------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
Filter: gpg4pine 4.2 (http://azzie.robotics.net)

iD8DBQE7WcOcNJmavqlTkb0RAm40AKDMq6P+f3SeA4DqaxyzUNPGKpu1UQCdFngS
aHSwp09r4e+7oZ9sP3QMF2g=
=5rWr
-----END PGP SIGNATURE-----