co z zamrazaniem dystrybucji

[Konrad Stepien]

On Sun, 10 Dec 2000, Tomasz Kłoczko wrote:

> 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.

No właśnie, jakby było jakieś frozen sprzed tych wszystkich zmian
(powiedzmy sprzed 3 miesięcy) to by wystarczyło to tego zrobić
ze 3 security updates.

[...]
> 
> > > 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ć.
> 
No i OK. W tej chwili akurat dopracowywanie niczym się nie będzie różmiło
od zamrażania.

[...]
> 
> > > 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".
> 
To nie koniecznie tak.
Jak będę miał chwile czasu do dociągnę wszystko co trzeba.
Jak stawiam nową maszynkę to już wszystko ma świerzutkie.
Akurat ostatnią stawiałem z czasie przechodzienia na glibc-2.2 i spółkę.
Dobrze że to była nowa maszyna, bo jak bym się wpakował z tym
na głównym serwerze to .....
Tylko że wpadki w PLD się zdarzają. Częściej lub rzadziej. Chodzi
mi o minimalizację ilości tych wpadek.

[...]
> 
> > 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ą.
> 
Zapewniam Cię, że --force dla mnie mogło by nie istnieć.
Na szczęście prawie zawsze można zrobić --rebuild z sourca i chodzi.

-- 
Konrad Stępień          | Hardware is indeterministically reliable.
konrad w interdata.com.pl | Software is deterministically unreliable.
InterData/PKFL		| People are indeterministically unreliable.
PLD Team		| Nature is deterministically reliable.