rel w EXTRAVERSION w kernelu

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pon, 29 Paź 2001, 01:05:48 CET


On Sun, 28 Oct 2001, Marcin Bohosiewicz wrote:

> On Mon, 22 Oct 2001, Tomasz Kłoczko wrote:
> 
> > On Mon, 22 Oct 2001, Blues wrote:
> > 
> > > On Sun, 21 Oct 2001, Tomasz Kłoczko wrote:
> > > > Co było przeciwskazaniem żeby wrzucać rel pakietu do 
> > > > EXTRAVERSION w kernelu ? Pamięta to ktoś ?
> > > 
> > > Binarne moduły nie lubią często extraversion. Nie "smakuje" im to...
> > 
> > Tak czy inaczje trzeba to wreszcie rozwiązać żeby można było uporządkowac 
> > lirca, i2c, lm_sensors i kilka innych :>
> 
> Tomek, a co sadzisz o metodach budowania pakietow z modulami
> do kernela w wersji UP i SMP? Teraz jest tak, ze czesc specow
> (chocby alsa) buduje i jeden i drugi modul (jako 2 podpakiety)
> a inne (nvidia,i2c,lm_sensors itd) wymagaja ustawiania --with smp
> co troche przeszkadza przy automatyzacji przebudowywania.

Wszystko wsazuje na to, że należałoby nieco zmienic wersjonowanie kerneli
i pakietów z modułami. Istnieje kilka nieco sprzecznych ze sobą celów:

1) powinno dać się zainstalować dwa kernele o różnych rewizjach ale o tej 
   samej wersji,

2) pakiety z modułami dodatkowymi powinny pasować do powyższego,

3) powinny być budowane kernele w wersji smp i up ale także powinny być do 
   tego uzupełniające pakiety z dodatkowymi modułami,

4) powinno dać się zainstalować na tej samej maszynce kernel i moduły smp
   i up,

5) pakiety z dodatkowymi modułami powinno się dać budować po za pakietem 
   kernela.

Tutaj chyba z tymi celami się chyba każdy zgodzi.

Żeby to osiągnąć trzeba przyjąć do wiadomości że po kazdej zmianie rel
pakietu kernela tzreba będzie przebudowywać pakiety z modułami.
Żeby osiągnąć punkt 3) trzeba przyjąć do wiadomości to że żeby uniknąć 
dwukrotnego wysyłania pakietu do przebudowania tylko po to żeby 
wygenerować wersje up i smp, i żeby unikąć tego że czy to smp czy up 
pakiety nie zostały przebudowane (i z tego powodu "gdzieś zgubione").
Z puntem 4) wiąże sie wydzielenie osobnych hierarhii w /lib/modules na 
moduły smp i up.

Żeby to osiągnąć wprowadziliśmy rożne wersjonowanie w kernelach up i smp. 
ciagna znaków oznaczający wersję kernela smp dostaje dodatkowo "smp" w 
nazwie i to umożliwia realizację wszystkich powyższych celów z punktu 
separacji zasobów smp/up.

Jeżeli przyjąć że chcemy osiagnąć w pełni punkt 1) to nalezy przyjąć do 
wiadomości że całość (kernel i pakiety z dodatkowymi modułami) jest 
przebudowwywana po kazdej zmianie rel pakietu kernela. I nie widzę innej 
możliwości realizacji po mimo tego że Janek sam wytykał to że to by było 
głupie w tym wątku.

Bez używania EXTRAVERSION za bardzo nie widzę możliwości realizacji 
wszystkiego w kupie. Przed chwilą jeszcze na wszelki wypadek zajrzałem do 
speca RH i zauważyłem że jednak oni pakują %{release} do EXTRAVERSION, a 
co wiecej wpada tam także "smp" o ile kernel jest w wersji smp. Czyli o 
ile gdzieś istnieja jakieś powody dla których używanie EXTRAVERSION jest 
nie wskazane to zapewne można/należy to olać.

Żeby osiągnąć przywiązanie podpakietów z modułami do konkretnej wersji/rel 
kernela należałoby przyjąć wesjonowanie podobne do tego co jest w 
util-linux czy kilku innych pakeitach, którym w rel wpadają informacje o 
tym do jakeigo to pasuje kernela, a w Requires dodatkowo odpowidnie 
regółki .. niemniej rozszerzone o takze pilnowanie rel pakietu kernela.

koments ?

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*



Więcej informacji o liście dyskusyjnej pld-devel-pl