Názory k článku
Jak upgradovat glibc na verzi 2.2 v RH 6.2

Ještě by bylo vhodné doplnit, že po nainstalování novější verze rpm je _velmi_ vhodné provést příkaz :

rpm --rebuilddb

Bez toho se může stát, že se poškodí databáze nainstalovaných balíčků a prý (podle několika dotazů v koferenci) pak rpm umí pracovat (a vidí) jen s balíčky, které byly nanstalované po jeho upg.
Nevím přesně, kolik je na tom pravdy, ale raději to pokaždé dělám. Tenhle jeden příkaz nikoho nezabije ...

Upgradoval jsem rpm na jednom pocitaci. Uz bych to neudelal. ;-) Balicky jsou videt vsechny, ale prestanou fungovat utility jako gnorpm nebo kpackage. Je nutno je znova prekompilovat s novou knihovnou.

Format databaze rpm 3.x a 4.x je jiny uz jenom z duvodu pouziti db2 a db3. Pokud se jenom upgraduje (to je stejne hrozny slovo), tak se vytvori soubory databaze, ktere se jmenuji decentne jinak. Je tedy opravdu potreba --rebuilddb, jinak se pracuje s novou databazi, ktera je uplne prazdna.
Ja jsem si to vytrpel uplne, nebot jsem potreboval nainstalovat cosi, od ceho jsem mel zdrojaky v rpm 4.0. Nicmene rpm 4.0 jsem nasel instalovatelne pouze v rpm 4.0 (priznam se, ze bych ve svete osvicenych programatoru hovadinu tohoto typu necekal). Takze nasledovaly zdrojaky, kompilace (tahani db3) atd...
Toz tak. Zdar

RPM 3.0.5 prece umi balicky z rpm 4.0. V cem byl problem?

Gcc3.0 by podle oficialnich stranek melo byt "we hope to release in the first half of 2001" a take by nemelo byt binarne kompatibilni s tzv. gcc2.96-7. Je docela dobre mozne, ze tuto proceduru bude clovek absolvovat dvakrat.

Chapu tenhle clanek dobre tak, ze nektere veci prelozene s glibc-2.1 nebudou fungovat s glibc-2.2 ? Jestli je to tak, tak to mam fakt radost, jako by nestacilo, ze se bude muset znovu prelozit vsechno napsane v C++ kvuli gcc.

nevim proc by se mnelo vsechno znovu prekladat, vzdyt system dynamickeho linkovani nabizi jednoduche reseni - proste mit na disku jak glibc 2.1 tak 2.2. Bohuzel, balikove systemy na to nejsou stavene - IIRC rpm -U smaze predchozi verzi programu vcetne knihoven. Jinak nevim presne co konkretne jste musel kvuli gcc prekladat znovu - posedni oficialni release je gcc 2.95.3 a to by mnelo byt binarne kompatibilni i s egcs. Pokud pouzivate nestabilni redhatovskou 2.96-XX pak je to ovsem o necem jinem :)

Ne. Glibc 2.2 s programy slinkovanymi pro 2.0 nebo 2.1 bude fungovat OK (mela by... nebude, pokud programator byl prase a pouzil interni funkce z glibc misto tech z verejneho API ;). Tady byl problem s upgradem RPM, _ten_ zbori zavislosti.

Ja nechapu jinou vec: proc je nutne upgradovat RPM na 4.0, kdyz upgraduji glibc? Obzvlaste kdyz RPM 3.0.5 format baliku pro ctyrku zvlada...?

snad by to nemel byt vubec zadnt problem aspon podle toho co se pise ve FAQu glibc2.0 s nejakym oznacovanim symbolu verzemi primo v knihovne... uz to jde ale trosku mimo me, takze radsi vic o tom ve FAQ,README,INSTALL primo ve zdrojakach glibc.

Distribuce Raw Hide není dost vhodná pro ostrý systém, protože je vývojová. Je lepší přejít na rovnou na verzi 7.1 (nebo 7.0), která je konzistentní a vyzkoušená.

jako root:
----------------------------------
# echo "deb ftp://ftp.sh.cvut.cz/MIRRORS/debian/debian testing main contrib non-free" >> /etc/apt/sources.list
# apt-get dist-upgrade
----------------------------------
hotovo

nebo staci ve vasem /etc/apt/sources.list prepsat 'stable' na 'testing', nebo pomoci dselect.....

no ja zkusil upgrade dva dny pred vyjitim clanku ...

po rmp -U glibc samo prestane vsechno fungovat, nefunguje ani ls, takze toho clovek moc nenazkousi. No, tusim jsem ze to tak dopadne, takze jsem byl pripravenej na rescue systemu.

udivuje me ze autor doporucuje rpm -U kdyz se teda tady v diskuzi take mluvi o tom, ze tam clovek musi mit obe dohromady (to ja bohuzel nemuzu protoze mi doslo misto na partition)


zajimavy je, ze kdyz jsem pomoci mc vykopiroval vetsinu knihoven z toho rpm, tak to zazbralo asi 5MB, zatimco po normalni instalaci to zabira asi 40

No nevim. Nedavno jsem upgradoval glibc na mdk-7.2 a dopadlo to velice dobre. Neni potreba mit obe dve, protoze uz v readme pisou, ze jen velmi malo programu nepojede. Zavislosti muzou byt problem, pokud neco chce natvrdo nektere knihovny, ale stacilo udelat link. Jedine co bylo potreba prekompilovat byl PAM, protoze tvrdil, ze unlimited u velikosti souboru je 2GiB.

tak to vrele nedoporucuju zdrojaky... na vytoceni je potreba vic jak 300m

Nepochopil jsem z clanku vyhodu proc delat upgrade stareho (RH6.2) systemu ? Ma-li dotycny k dispozici r00tovske heslo a pristup na net mohl predsi upgradovat na 7.1 ??!!??
Ja ve skole pracuji na SUSE 6.2, (stare,unstable) a jako user jsem "upgradoval" na libc 6.2 pomoci LD_LIBRARY_PATH a mohu rici, ze skutecne s tim byl problem ;) Ocenil bych tedy clanek, jak provozovat
nove programy (DDD) pod starou libc.
Nastesti jsem novou knihovnu odstranil prikazem "Bzip2 libc.so.6" a system byl zase funkcni.

Dneska se mi to uspesne povedlo na Mandraku 7.1 a ani to nebolelo. Jen sem mal maly problem s locales. Po instalaci nove glibc je bylo potreba upgradovat z Mandrake 8.0, pak teprv vsechny programy zacali fungovat spravne cesky. Dale bylo potreba upgradovat libstdc++ protoze neslo vubec nic co bylo v c++ prelozit. Zajimave, ze bylo potreba preinstalovat jen libstdc++-devel, libstdc++ rvalo 1000 chyb v zavislostech, tak sem se na to vykaslal. kupodivu stacilo devel :-)

Redhat je $hit. Instalujte ze zdrojaku!