Budowanie zależnych od siebie pakietów (Re: 2.2 vs 2.4 -- propozycja)

[Paweł A. Gajda]

poniedziałek 23/07/2001 13:46:43, Tomasz Kłoczko:
> On Mon, 23 Jul 2001, Paweł A. Gajda wrote:
> > 
> > No i? Twierdzisz ni mniej ni więcej, że problemem jest budować 
> > łańcuszek: kernel, alsa, etc; natomiast budowanie samego kernela 
> > będzie łatwiejsze... W którym miejscu i dlaczego?  
> 
> Twierdze, że *urzymanie* tego (nie kompilowanie) w stanie spójnym (w
> zasobach wynikowych) w tych warunkach nie nasteczać bezie jzu kłopotów. O
> ile juz wyprodukujesz binarki nowego kernela to one nie ma bata ale nie
> bendą miały już żadnej możliwości rozjechania się :)

To samo da Ci sprytny skrypt, który naszkicowałem w pierwszym
poście, racja czy nie? 

Co więcej załatwiłby także analogiczne przypadki.

> 
> > > - moduły do kernela ładuja w katalogu zaleznym od wersji.
> > 
> > To bez znaczenia. Wystarczy dać pakietom zależnym od kernela 
> > odpowiednie zależności. 
> 
> Czego można uniknąć. Mozan uniknąć ytego zamaiszania.

...stosując odpowiedni mechanizm bez rezygnowania z modularności 
speców. 

> 
> > > Dodatkowo do pierwszego punktu dochodzi to ze częstoś zmian w kernelu jest 
> > > o conajmneij rząd wielkośic wiksza niż dla bibliotek.
> > 
> > Aha... no i? :->
> 
> No i pomyś teraz chwilę :)

No i skrypt załatwiający takie (częste przecież) przypadki wymyśliłem :-)
Naprawdę aż dziw, że nie dostrzegasz tego że załatwiłby to samo!  

> > 
> > Ponieważ kernel się często zmienia, a moduły zależą od wersji tegoż, to jak 
> > to będzie w kupie, to przy zmianie wersji/rel kernela nie trzeba się będzie 
> > bawić z budowaniem całego szeregu pakietów. 
> 
> Dokładnie. Ująłeś to już w taki sposób że zwieźlej się już chyba nie da :)
> Żeby dodać temu kolorów tzraba to jeszcze podeprzeć kikkoma argumentami
> popierajacymi tezę o tym, że w tym wypadku można pozwolić sobie na swego
> rodzaju odstępstwo ponieważ integralność jest tu celem nadrzędnym i
> jednocześnie dużo wyższym.

Czekam niecierpliwie na owe argumenty.

> 
> > A ja tylko chciałem zapytać: po co robić z tego jednego speca, skoro można 
> > załatwić problem "rozjeżdżania" ogólnym machanizmem??
> 
> No .. po to żeby to nie miało moliwiości rozjechania się.

Nie będzie miało możliwości także przy zastosowaniu skryptu 
który puszcza na buildery całe drzewka zależności. Racja czy nie? :-) 

> Paweł i tak zapewne dużo w tym zasobie nie będzies zapewne modyfikował 
> czyli argument o pracochłonnosic mozna odłożyć na bok. Zresztą po to się
> wczęsniej inwestuj czas żeby potem od tego odcinać kupony. Otóz twierdzę, 
> że to jest dobra inwestycja i przyniesie ona poprawę stanu w krórym w tej 
> chwili nawet zasoby modułów mamy rozjechane (moduł do svglib i 
> potencjalnie niejasna sytuacja na lini smp/up z modułem do masq).

jw.