2.2 vs 2.4 -- propozycja

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Nie, 22 Lip 2001, 20:22:13 CEST


On Sun, 22 Jul 2001, wrobell wrote:

> On Sun, Jul 22, 2001 at 07:45:07PM +0200, Tomasz Kłoczko wrote:
> > On Sun, 22 Jul 2001, Jacek Konieczny wrote:
> [...]
> > > IMHO najlepiej by było umieścić wersję  kernela w rel., jak ktoś już
> > > wspominał. To byłoby przydatne nawet przy kernelach tej samej serii.
> > 
> > Jeszcze raz. Dołożenie asly spowodukje wydłuzenie całosci o czas mneij 
> > wiecej potzrebny na skompilowanie modułów pcmcia-cs bo ilo0ść modułow i 
> I za każdym razem jak wyjdzie nowa alsa, to będziesz rekompilował na builderach
> cały kernel?

Proponuję zerknąć ile razy miało to miejsce przez ostani rok i w drugiej 
ręce zważyć to że zmian innego rodzjau w kernelu bezie o rzad jak moze 
nawet i dwa wiecej, i przy każdej takiej zmianie bezie kolejna okazja do 
rozjechamnai ie werji modułów.

> Moim zdaniem lepiej zostawić alsę w osobnym pakiecie
> aż do kernela 2.6, kiedy to najprawdopodbniej alsa będzie oficjalnie
> w jajku zintegrowana.
> 
> Poza tym czasami się zdarza, że najnowszy kernel wprowadza takie
> zmiany, że alsa się z nim nie kompiluje. Co wtedy?

Dajesz sobie odpusk z nowym kernelem skoro jego użuwanie nie ma i tak 
sensu (nawet gdyby alsa w takim przypadku była w osobnym pakiecie).

> Czekasz
> na nową wersję alsy? Kompilujesz kernel bez alsy? A nie lepiej
> skompilować pakiet z samym kernelem, a pakiety z alsą wywalić
> z ftp-a i poczekać na nowszą wersję alsy i jak się już ukaże,
> to przekompilować _tylko_ pakiet z alsą i wystawić go na ftp-ie?
> Nie jest tak prościej?

Zawsze mozęsz wypuścić kernel bez alsy. Wycięcie akutrat tego powinno sie 
dać zrobic na sto procent bcondem, bo ala nei wchodzi w interakcje z 
innymi modułami.

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