Budowa modułów--propozycja

[Tomasz Kłoczko]

On Tue, 31 Jul 2001, Paweł Sakowski wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Do rozwiązania AFAIR są dwie kwestie: [1]budowanie modułów dla 2.2 i 2.4 z
> różnymi zestawami kernel-headers i [2]automatyzacja budowy po
> przebudowaniu jądra. Oto moje propozycje na ten temat:
> 
> - ----
> 
> [1] Wymyśliłem, żeby do speców od modułów dawać na początku:
> 
> %if %{?kernel_dir:0}%{!?kernel_dir:1}
> %define		kernel_dir	/usr/src/linux
> %endif
> 
> %define		_kernel_ver	_kernel_ver %(grep UTS_RELEASE
> %{kernel_dir}/include/linux/version.h 2>/dev/null | cut -d'"' -f2)
> 
> i odpowiedni kawałek w build, żeby budować z %{kernel_dir}, nie
> /usr/src/linux (chciałbym zauważyć, że jeśli %{kernel_dir} jest
> niezdefiniowany, budowanie przebiega jak dotychczas). Wtedy na builderach
> możnaby (po napisaniu odpowiedniego kawałka kodu) po zbudowaniu kernela
> odpalać coś w stylu:
> 
> ./builder -[...] --opts "define kernel_dir\ /usr/src/linux-2.4.7" \
> alsa-driver-up.spec
> 
> Pożądaną wersję jądra możnaby przekazywać jako opcjonalny parametr (obok
> X-Spec) do buildera, który rozwijałby ją do opcji budowania jak powyżej.
> 
> Do tego jeszcze na builderach trzebaby trzymać dwa zestawy kernel-headers,
> ale z tym nie ma dużego problemu: rpm -i kernel-headers-2.2.19-16;rpm -i
> kernel-headers-2.4.7-4 --force  i już.

OK. Propozycja tylko żeby może nazwać to makro nieco inaczej żeby nie 
kojarzyło się z kernelem co ze źródłami kernela (_kernelsrcdir albo jakoś
tak). To makro możesz już wrzucić do naszego macros.

> - ----
> 
> [2] Po zagłębieniu się w organizację pracy builderów doszedłem do wniosku,
> że nie tak łatwo byłoby zautomatyzować budowę modułów po jądrze.
> Wymagałoby to:
> 
> - - automatycznej instalacji nowo zbudowanych kernel-headers. Pytanie
> tylko jak? sudo? rpm2cpio|cpio -i? Oba rozwiązania nieeleganckie.
> 
> - - rekurencyjnego wywoływania buildera w przypadku ${BSPEC} = kernel.spec.
> To jest już prostsze, ale gdzieś trzeba trzymać listę speców modułów.
> 
> Wydaje mi się, że można dla rozwiązania tego zadania pokusić się o
> półautomatyzację, tzn stworzyć skrypt SPECS/build_kernmod_request o
> treści mniej więcej:
> 
> #!/bin/sh
> DIR="`rpm --eval '%{_specdir}'`"
> VER=$1; shift
> ARCHS="$*"
> build_mod()
> {
> 	echo "Requesting build of $1"
> 	$DIR/buildrpm_request --kernver=$VER $1.spec $ARCHS
> }
> build_mod alsa-driver-up
> build_mod alsa-driver-smp
> ...
> 
> A następnie uprzejmie poprosić administratorów builderów o wykonywanie
> tego skryptu po instalacji na builderach nowych kernel-headers. Jeśliby
> przyjąć, że ten skrypt byłby użytkowany _tylko_ przez administratorów
> builderów, to na jego górę (dla większej automatyzacji) możnaby wstawić
> rpm --root=... -i kernel-headers-...rpm.

To jakie pakiety powinny ulec przebudowaniu wychwycić jest prosto (grep po 
makrach do wersjinowanai kernela. Spece zawierające %{_kernel_ver} powinny 
pójść do przebudowania. Sygnał o tym może iść choćby z pld-builder 
zwrotnie jako ostrzeżenie. Docelowo to samo źródło sysgnału moze zostać 
wykorzystane do automatycznego podbicia wychwyconych pakietów i wysłania 
zleceń ich przebudowania choć na razie zostawiłbym tylko wysyłanie w 
buildlogu wrzucenie zwrotnie informacji o przebudowaniu kernela. Przy 
automatyzacji (na poPGPowane zlecenia) instalacji/upgrade pakietów na 
builderach moze być wykorzystane wychwycenie instalacji nowej wersji 
kernel-headers do tego żeby dodatkowo automatycnie podbić rel i wysłać 
zlecenia przebudowania kilku pakietów zawierających moduły.

Tak czy inaczjezbadAĆ JESZCZE trzeba czy takie moduły jak svga czy lirc są 
zależne od SMP/UP.

> - ----
> 
> Dodałbym jeszcze, że po wprowadzeniu "znakowania" modułów (@%_kernel_ver,

Z znakiem "@" jest pewien mały kłopot. Nie może być on używany w eykietach 
cvs-a, a nazwa, wersja i rel pakeitu są uzywane przy konstuowaniu 
etykiety. To trzeba bęedzie jeszcze jakioś obejść (albo inny znak albo 
przy konstruowaniu nazwy etykiety @ zastepować vczymś innym co bezie 
akceptowane przez cvs).

> Conflicts: kernel != %_kernel_ver), wykrywanie niespójności zasobów staje
> się łatwiejsze. Programy typu apt powinny (chyba, bo ich nie znam za
> bardzo) alarmować w przypadku natrafienia na niespójność.

Tak. W tym wypadku co prawda robi to wuch ale to załątwia sprawę.

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*