Budowanie zale?nych od siebie pakiet?w

[Tomasz Kłoczko]

On Mon, 23 Jul 2001, Paweł Sakowski wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Zauważyłem takze, że już choćby Ty nie
> > zauważasz tego, że po takiej zmianie bałagan z niespójnością zasobów
> > modułów zniknie raz na zawsze.
> 
> Podobnie znikną ltmodem i lirc. Bo ja będę musiał rzucić to w cholerę
> 
> > > No i zastanów się chwilkę.... czy tu jest tylko jedna osoba które umie
> > > logicznie myśleć?
> > 
> > Zauwazam to. Żauważam takze to że podczas tego myślenia łatwo przecjhodzi 
> > się do porżadku nad tym co wymieniam (ergo: jest to logiczna jak 
> > najbardziej analiza faktów ale w zakresie neikompletnym).
> 
> No to przejdźmy na fakty. Jakie problemy stwarza rozbicie jądra i modułów
> na kilka pakietów? Słownie jeden: zdarza się, że zasoby się
> rozsynchronizują przez przebudowanie jądra a modułów nie. Rozwiązania są
> dwa: łączenie speców lub zautomatyzowanie przebudowy modułów po jądrze.

Dorzuć do tego, że moduły musża być w dwuch wersjach: smp i up.

> To drugie już było proponowane, i to w bardzo konkretnej formie; są
> osoby chętne, żeby to zrobić. Owszem, twoje rozwiązanie jest prostsze
> i szybsze, ale ma też poważne wady: Każdy, kto będzie chciał coś robić
> przy modułach, musi się uzbroić w duużo cierpliwości i miejsca na
> dysku. Doświadczenie uczy, że próbując coś poprawić w specu robi się
> ok. 5 przebudowań. Mnożąc to przez jakieś 6 godzin (strzelam, bo się
> nigdy nie doczekałem) budowy jądra dostajemy 30 godzin, czyli trzy dni
> z życia normalnego człowieka. Spędzisz tyle z nową wersją ltmodem? Bo
> ja nie. Zatem efektem ubocznym takiego postępowania byłoby postępujące
> zamrażanie dystrybucji -- przynajmniej w przypadku utrzymywanych
> przeze mnie lirca i ltmodema, do których po włączeniu w jądro już bym
> się nie dotykał.

O ile jakaś poprawka dotyka plików nagłówkowych to tego typu zmiana będzie 
dotyczyć reszty pakietów. W kupie czy nie tego typu szczegóły wyjdą i ta. 
O ile wyjdą to sumaryczyny czas budowania pakietów bezie niewiele wiekszy 
niż dla całosći. O ile tego typu zmiana nie bezie dotykać takich spraw 
mozńa załozyć że konkretna zmiana będzie dotyczyć tylko tych plków które 
jakaś poprawka bezie dotykać, czyli na resztę zasobów to nie wpłynie. 
Potencjalnie ilosć kompilacji spada do jednej, dwuch no moze tzrech sztuk. 
Zdajac sobei sprawę z ograniczonego dziaąłnia poprawki można po pierszym 
nieudanym budowaniu testować już to co jest rozpakowane usuwajac jakieś 
błedy po to zeby na koniec wykonać jeszcze raz ostateczna kompilację 
całosći.
W sumie na podstwie tego co jest juz w kernelu daje sie zauwazyć jedno, że 
zmiana raz zintegrowana nie wchodzi raczje w interakcje z innymi potem. 
tak się raczej zdarza, że wydatek czasowy jest niejako jednokrotny
i niemal jestem peien tego że jeżeli raz dołożyłbyś patcha do kernela na 
moduł od lirc to juz byś sie wiecej tego nie dotykał. W tym sensie jest to 
na pewno identyczny wydatek czasowy w późniejszym etapie i nieco wiekszy 
na początu kiedy całosć sie integruje z kernelem.
Ale jeszcze raz .. co sie zyskuje pzrez totalne zgrupowanie tego ?
Otóż ma się pewność że zasób tak wazny jak kernel i moduły do niego jest 
prawidłowo budującyc się i to niezależnie od środowisk na jakich to 
przyjdzie budować.

> > Po drugie nie jest to moja idea. Jest to *czyste rozwiniecie* tego co 
> > Janek kiedyś zrobił i co *do dzisiaj się dobrze sprawsdza*
> 
> I następnym krokiem byłoby pewnie zintegrowanie glibca (też zależy od
> wersji jądra)? W pewnym momencie trzeba przestać i ten moment już
> nastąpił.

Idziesz za daleko. Zatrzymaj się dokładnie tam gdzie trzeba. Nie ma sensu
próbować nawet ekstrapolować tego podejścia dalej. Wszystko wynika z tego, 
że kernel i jego moduły jest zasobem szczególnym. Pewne szczególne regóły 
jeżeli już mogą tylko obowiazywac w ramach kregu tego typu zasobów i to 
jest ten moment gdzie trzeba przestać.

> > Mam też namacalne skutki tego że brak tego podejhścia
> > skutkuje tym że mamy te zasoby rozjechane, a przy przejściu na 2.2.19 
> > sporo czasu alsa nie była także zaktualizowana (nawet nikomu nie 
> > chciało się podbić rel pakietu żeby zasygnalizować że przebudowanie 
> > jest potrzebne).
> 
> Daj mi dostęp do builderów, a za tydzień będziesz miał gwarancję, że to
> się nie powtórzy i za jądrem będzie przebudowywane wszystko, co tego
> wymaga. I to bez utrudniania życia ludziom od modułów.

Nie ma sprawy. Dam Ci jak poprawisz svgalib. Bez tego dotykanie builderów 
pod kontem modułów nie ma najmneijszego sensu.

> > Błędem moim było w tym wypadku to że wciągnąłem się w dyskusję publicznie.
> > Powinienem to skonsultować z przykładowo Jankiem i Arturem (czyli 
> > osobami które wiedzą sporo o zasobach których dotyczy sprawa bo same
> > brały aktywny udział w ich preparowaniu czyli kernel i alsa) i co
> > najwyżej tylko te osoby przekonywać. W sytuacji kiedy miałbym 
> > dgotową poprawke (której sporządzenie zajełoby mi mniej czasu niż ta cała
> > dyskusja) przekonywać mógłbym żywym zasobem (byłoby to juz bardzo łatwe).
> 
> Oj, tylko proszę bez takich machiavellizmów. Z tego, co pamiętam to tą
> dystrybucję robimy zbiorowo. Stawianie ludzi przed faktem dokonanym
> (czyt. uzurpacja) raczej nie pasuje do takiego modelu pracy. Mimo, że
> jesteś osobą najintensywniej się tu udzielającą.

To nie jest tak. Zauważ jak często ludzie na około Ciebie mówią ci że coś
nie ma sensu czy też jest niwykonalne tylko dlatego że nie mają możliwości
dotkniecia żywego przykładu. Cały wątek 2.4 vs. 2.2 jest dokładnie
ilistracja tego czegoś. Janek tak samo jak ja popełnił ten sam błąd.  
Zamiast trzema słowami na krzyż dajac do zrozumienia, że odejscie od 2.2
juz jest tuż tuż nie dajac przy tym mozliwośći szybkiego sprawdzenai jak
2.4 działa powinien najpierw przyszykować całe zaplecze do tego przejścia
(szukajac moze kogoś do pomocy żeby to zrobić szybciej). W tej kiedy to
krótkie sformułowanie/ucięcie 2.2 nie skomentował odpwoeidnio w sytuacji
kiedy napisałby już po przyszykowaniu zapleca "tu są zasoby .. spróbujcie
tego, a zapewne zgodzicie się ze mną, że w zasadzie możemy już odejśc od
2.2" wywołałby raczej zadowolenie, entuzjazm, cheć do wykonywania 
szerszych prób niż efekt zwięrzątka zapędzonego w przysłowiowy róg.

Tego typu działanie na pewno nie byłoby manipulacją czy też stawianiem
przed faktem dokonanym dokładnie tak samo mogło być z kernelem grupujacym 
moduły w jednym pakiecie źródłowym.

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*