co z zamrazaniem dystrybucji

[Tomasz Kłoczko]

On Sun, 10 Dec 2000, Konrad Stepien wrote:
[..]
> > Teraz pytanie: co Twoim zdaniem jest do ustabilozowania ?
> > 
> Moim zdaniem, takie coś, że nie wprowadzamy np. nowych bilbiotek
> jeśli nie ma potrzeby. Dzięki temu nia mam obowiązku instalować
> _każdej_ nowostki jaka się pojawi na ftp, bo bez tego np. nowy bash
> mi się nie założy.

Moment bash używa, glibc, readline i ncurses. Blokowanie z tego powodu
wszelkich ruchów w bibliotekach to lekka głupota.
Mi osobiście wystarczy ze widze changelog w którym mainatainer cos
wspomina o pousuwaniu jakis błędów. Tak czy inaczej wprowadzanie tu jakis
sztywnych reguł to nie jest to.
Były grube przejścia typu, glibc, rpm, tcl/tk czy przejście na uzywanie
wyłacznei db3. To sie skończyło. jeszcze raz .. potencjalnie teraz moze
jeszcze być tylko perl i OpenLDAP. W przypadku tego drugiego mielizn nie
ma i w zasadzie czeka to juz tylko na rozwiązanie kwestii związanych z tym
dlaczego niechce sie to przebudować na niektórych builderach.
W tego typu zmianach chodzi o pewiemn racjonalizm działani. Glibc
wprowadzaliśmy ponieważ potrzebne było to do ipv6, rpm-a 4.0 ponieważ jest
to jedyna wersja używalna na glibc 2.2, odejścieod db{1,2} zostało
zrobione po to zeby uporządkować cały ten bur^H^Hałagan, tcl/tk ponieeważ
staffy te nie były aktualizowane od prawie dwuch lat i w miedzyczasie
wszyscy zaczeli juz używać czego innego, python 2.0 z podobnych powodów,a
przyokazji została wprowadzona wersja shared biblioteki pythina.
Za każdym z tych kroków które mogły wpływać na stabilność całosci stały
jakieś racjonalne powody. To nie było zwykłe WidzimiSię bo na ftp leżały
nowsze archiwa ze źródłami.
O glibc 2.2 można powiedzić jeszcze tylko tyle że przejście jest to tyle
wskazane o ile ktoś używa nscd bo dopiero w tej wersji usunieto kilka
paskudnych błędów o których zapewne mało kto wie i juz zapewne mało kto
sie dowie o ile w miedzy czasie poszedł za czołem zmian.

> > Mówiłem już, że po wprowadzeniu perla 5.6 i OpenLDAP 2.0.x nie będzie już
> > w zasadzie nić ciekawego i grubego co mogłoby wpłynąć na resztę zasobów
> > .. nawet ewentualne przejście na kernel 2.4 też już mało co zmieni.
> > Z perlem jest kupa roboty, a OpenLDAP narazie nie wiedzieć czemu nie chce
> > sie budować na 586 i 386.
> 
> No i to moim zdaniem super moment na zrobienie frozen.

Do moemntu kiedy nie zostaną uporządkowane te dwie sprawy tak czy inaczej
nie ma pwodów żeby nieaktualizować tego czy innego pakietu o ile pojawi
się nowsza wersja. poperostu widać, że suma sumarum wpływa to na
polepszenie jakosci całosci bo połykamy w ten sposób pracę nad
dopracowywaniem poszczególnych pakietów jaką wykonali maintainerzy.
Jest coraz wiecej pakietów któreych upgrade mozan robić niemal na pewniaka
poprzez wymiane wersji .. i nalezy się tylko z tego cieszyć i korzystać.

Zamrożenie załości bezie w tym wypadku polegać na pokopiowaniu chrootów
builderów po to zęby w razie czego można było w konkretnych warunkach
wyprodukować jakiś pakiet i to wszystko.
Dalej w tym wszystkim dnic sie nie zmieni i całosć będzie się toczyć z
taka prędkością do przodu jaka jest tylko możliwa.
Może nawet będzie mozan gdzieś zarchiwozować całe te chrooty i wystawić je
gdzieś na ftp. Osobiście nie zamierzam za dużo temu poświecać uwagi dopóty
dopóki bedzie to tylko możliwe.
Po drugie postawienie krzyrzyka w którymś miejscu tak naprawdę mało co
zmienia. Ludzi którzy beą w stanie usuwać błedy pójdą do przodu
zapominając o tym co było w którymś tam miejscu. Potencjalnie konserwacja
tych zamrożeń może sprawiać sporo kłopotów (ale to już inna sprawa).
Nie chcę tu kwestionować bymnajmniej potrzeby takich zamrożeń tylko
próbuję objąć fakty z tym związane.

> > Wchodzenie np. KDE 2.x bezie już robione bez zagrożenia dla reszty.
> > 
> > Kolejne wersje programów są zwykle coraz lepsze i stabilniejsze, z
> > mniejszą ilością błędów. Wstrzymywać się z ich wprowadzaniem *nie ma sensu*
> > bo powstają zaległości i nie są usuwane błędy które zostały zauważone na
> > poziomie poszczególncyh paczek przez maintainerów do których nawet
> > niejednokrotnie nie mieliśmy szansy dotrzeć.
> > 
> No i te nowe wersje często mają nowe błędy (robione na poziomie
> poszczególnych paczek).

Inaczje. Masz czas i możliwości usuwac stare błędy ? piszesz że masz ledwo
co tzrymajacą sie instalację z sendmailaem i nie masz czasu choćby na to
żeby doprowadzić to do jakiegoś porzadku.
Mówisz niemal wprost "nic nie robię i doradzam to samo innym".

> Sens zamrożenia widzę taki, że mój nakład pracy na utrzymanie serwerów
> się drastycznie zmiejszy. Updaty robię tylko wtedy gdy muszę.

Szczerze mówiac wszystkie swoj produkcyjne systemy staram sie utzrymać up
to date. Robie tak od tak dawna jak tylko jestem w stanie siegnać pamiecią
wstecz. Były z tego tytułu różne kłopoty ale jak popatrze na znajomych
którzy zaniedbywali utrzymywanie sytemów w dobrej kondycji to jestem
zadowolony że tak robiłem i robić tak bendę dalej. To jest poprostu tańsze
i mniej zajmujące czasu, a o strachu wynikajacym z przestawiania po
dłuższej przerwie nie wspomnę.
Wydaje sie to neiracjonalne ale jeżeli zdać sobie sprawę z tego że soft
jaki jest dosepny pod L po mimo i tak włożeonej potęznej porcji uwagi,
czasu i energii dziesiatków tysięcy ludzi jest nadal mocno czasami
niedporacowany to dojść można do wniosków że posuwanie się za czołem zmian
możliwei blisko jest dość jednak racjonalne. Było juz kilk przypadków w
których wychodziły jakieś błędy klasy nawet secutity i okazywało się że
cała sprawa nas akurat nie dotyczy bo autor w ostaniej wersji po cichu
usuną tą czynna dziurę, chwila potem u nas pojawiał się pakiet i dopiero
po kilki czy też nastu dniach wychodziło na jaw że w zasadzie pakeit XX to
tzreba instalować ASAP. Tak było raz z bindem, drugi raz było z manem.

> Teraz sprawa wygląda często tak, że jak muszę zainstalować
> nowy pakiet, to mam nagle 50 pakietów do upgradu.
> Często kończy się to tak, że robię backporta do starszej wersji.

Widzisz stary .. zawsze masz coś takiego jak opcje --test w rpm-ie. "rpm
-U --test <pakiety>" pokaże Ci co jest potencjalnie nie tak z
zależnościami. Wystarczy na to zeknać i ocenić czy juz w tym momencie mogę
wykoanć pełne pzrestawienia całej grupy pakeitów czy jeszcze wypadałoby
poczekać. To jest jedna strona. Druga wyglada tak, że jeżeli widzisz
patrząc na to co pokazuje Ci rpm uruchamiany z --test co jeszcze nie jest
podciagnięte, a co byś potrzebował to zawsze możesz pomóc żeby ewentualne
stany nieustalone skrócić do minimum.

Konserwacja systemu w ten sposób jest jak najbardziej racjonalną
dziedzina. Przewidywalną i opisywalną, z własna metodologią postępowania
której przestrzeganie minimalizuje ewentualne negatywne skutki. Robienie
czegoś na rympał z machaniem ręką na zależmności niczym dobrym sie nie
kończy .. a tylko w takiej systuacji zwykle takie upgradey grupami kończą
się jakimiś niespodziankami. Druga sprawa, że rózne drobiazgi jakie
wychodzą przy instalacji/upgrade powinno dobrze byłoby jednak
zgłaszać. Tu mogę sie zaożyć że wile osób wiele razy widziało rózne drobne
nieprawidłowości i machało na nie ręką. To nie jest mądre bo prędzej czy
później zemści się to bolesną czkawką.

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*