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