Budowa modułów--propozycja

[Paweł Sakowski]

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

- ----

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

- ----

Dodałbym jeszcze, że po wprowadzeniu "znakowania" modułów (@%_kernel_ver,
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ść. Poza tym na
podstawie samych nazw plików można napisać prosty skrypt sprawdzający, czy
przy istniejącym kernel-2.2.X-Y.*.rpm instnieją pliki *@2.2.Z-W.*.rpm,
gdzie Z!=X || W!=Y (to samo dla 2.4). Taki skrypt możnaby nawet wstawić w
jakiegoś crona, żeby alarmował kogo trzeba.

+--------------------------------------------------------------------+
|   Never trust a man who can count   :            Paweł Sakowski    |
|      up to 1023 on his fingers      :   <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)

iD8DBQE7ZttYNJmavqlTkb0RAtNoAKCeYuE/kCYpo832NUIE/MOmfCzWjACfR1c3
117i6thcXMjLKz8Ujfi7120=
=jcKb
-----END PGP SIGNATURE-----