AC, NEST i inne pierdziawki Re: SPECS: glibc-kernheaders.spec (NEW)

[Witek Kręcicki]

W liście z pi?, 30-05-2003, godz. 00:42, robert j. wozny pisze: 
> Quoting Andrzej Krzysztofowicz <ankry w green.mif.pg.gda.pl>:
> 
> >> Ac za cenę możnowładztwa Tomasza? - wybieram Nesta.
> > Mysle, ze jak tak dalej pojdzie, to Ac w ogole nie bedzie. A szkoda.
> >> > Przez _plynne_ rozumiem, ze np. poldkiem.
> 
> moze khm. lepiej to od razu ustalic/powiedziec, whatever.
> 
> 1. bezbolesne, plynne przejscie proponuje zrobic w obrebie RA - czyli
>    serii 1.x - tam to powinno byc super plynne. 
> 2. bolesne przejscie zrobic pomiedzy 1.x a 2.x - czyli jezeli AC to
>    2.x to sorry. ale bezbolesnego plynnego przejscia nie uswiadczymy.
> 
> ad1: to jest normalne.
> 
> ad2: jezeli bierzemy pod uwage to, iz zmieniamy glibc'e i gcc... i
> rpm'a i ... to przejscie moze byc trudne - po zmianie glibcow
> statyczne programy moga zrobic akuku. nie ma _chyba+_ na to rady - poz
> aopublikowanymi skryptami - leczacymi skutki a nie powod
> problemu. uwazam ze tym samym _NIE_ ma mozliwosci zrobienia AC tak,
> aby przejscie bylo bezbolesne. 
Tutaj chyba głównym problemem jest 'bezbolesna' aktualizacja RPM/glibc i
pochodnych. Moja propozycja skryptu który to by robił (RFC):
1. Upgrade jadra. Restart i automagiczny powrot do skryptu
2. poldek ściąga glibc (bez -devel), iconv, rpm + zależności (rpm-libs,
elfutils-libelf, libpopt etc.) + poldka
3. Tu uzywany jest statyczny, totalnie niezalezny RPM gdzies
udostepniony:
   a) mv /var/lib/rpm/Packages someplace; rm -Rf /var/lib/rpm/*. mv
someplace/Packages /var/lib/rpm; rpm --rebuilddb
   b) rpm -Uhv --nodeps glibc .....
4. rpm -Uhv poldek
5. poldek kontynuuje dzialanie uzupelniajac bledy w zaleznosciach
(glibc-devel, etc)
6. Poczatek reszty upgrade. 
Oczywistym jest, ze upgrade do Ac musi przebiegac 'calosciowo':
pozostawienie czegokolwiek z Ra (szczególnie rzeczy napisanych w
C++/linkowanych z libstdc++) predzej czy później bardzo brzydko się
odbije. 
WK