2.2 vs 2.4 -- propozycja

[Tomasz Kłoczko]

On Sat, 21 Jul 2001, Paweł Sakowski wrote:

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

NIc samo się nie stanie. Ja nie jestem zainteresowany na razie 2.4 i
napisałem takze wyraźnie co tzreba *zrobić* żeby zasoby do 2.4 się
pojawiły. powtórzę w taki razie co to było:
- brabche w specach do zasobów które tego bendą wymagać,
- skompletowanie jednoznacznej listy takich zasobów
 
> 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).

Zanczy się zaznaczać w rel tego typu informacje. Zasada do przyjęcia. Tyle
że w rel zdaje się że nie wyda używanie jako separatora "-" i zatapiśc to
trzeba bedzue innymm znakiem. zxapewne "_" albo ".", a o ile przeszłoby
przez rpma to dałbym "#" (nawet jeżeli "-" były łykany przez rpm-a bo
bedzie to znacznie wyraźniejsze do identyfikacji).

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

Proponuję nie wnikać w to jak to działa. Sprawa Związana z używaniem
środowiska raczje do 2.2 lub raczje do 2.4 jest przejściowa i nie
zaprzątałbym sobie tyl głowę. Jeżeli bezie lista pakeitów które powinny
być przekompilowane pod 2.4 to zmieni sie czasowo kilk pakeitów i całosć w
zestawie przekompiluje.

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*