Administrace komentářů

Začal bych tím upgradem. Měl by být bezpečný, a to i v případě, že by třeba uprostěd aktualizace vypadl proud. Nejprve se aktualizují systémové knihovny, pak až třeba balíčkovací systém, potom grafické prostředí. Pokud to uvázne někde na půli cesty, nemusí třeba naběhnout grafické prostředí, a potom je potřeba to opravit z terminálu pomocí aptitude. Mně se to ale nikdy nijak zásadně nerozbilo. Do jaké míry je ta aktualizace interaktivní si už moc nepamatuju, přinejmenším to ale vypíše, co se na tom kterém balíku změnilo, a zálohuje to staré konfiguráky, tak, jako při dílčích aktualizacích.

Tak jako tak ale není od věci systém zálohovat, tj. zabalit si adresáře /etc, /usr, /bin, /sbin, /var, /boot, pamatovat na přípojné body /dev (a zařízení /dev/null a /dev/console), /proc a /sys, případně ještě zabalit /opt. Ideální je, pokud jsou data oddělena od systému, pak je nejsnazší zabalit kořenový oddíl / a všechny oddíly pro výše uvedené adresáře, pokud je tak systém nainstalovaný. Ale to je tu v poradně popsáno na mnoho způsobů.

A teď ke knihovnám. Pokud se instalují balíky napříč distribucemi, je dobré, když mají aspoň společný balíčkovací systém (jako Debian a Ubuntu). Potom by si měl balíčkovací systém závislosti pohlídat sám, a není potřeba si s tím moc hrát. Ale když to nejde, dá se takový balíček vybalit ručně (třeba do /usr/local). A nějak mu doplnit chybějící knihovny. V lepším případě přes balíčkovací systém, a když to nejde, tak nahrát tam, kam balíčkovací nástroje nesahají, typicky do /usr/local/lib. Pokud se přenáší nová binárka do starého systému, tak můžou vadit především dvě věci:

• staré jádro,
• stará knihovna libc.

Narazil jsem na to při přenosu binárky z Debianu 6 Squeeze do CentOSu 6. Program šel zprovoznit dvěma způsoby:

• zkompilováním v novém systému a statickým linkováním,
• zkompilováním ve starém systému.

Knihovna libc má v zánovním systému nějaké požadavky na minimální verzi jádra, a s tím toho nejde moc udělat. Snad by se to dalo přirovnat k situaci, kdy program pro Win2K/XP nejede ve Win9x.

Ani přenos starého programu do nového systému se nemusí podařit. Příkladem budiž knihovna pro práci se JPEG obrázky. Některé programy vyžadují verzi 6.2, zatímco např. v Debianu (snad Squeeze i Wheezy) je verze 8, a nějak se mi nepovedlo zprovoznit je současně včetně hlavičkových souborů (tady šlo o ručně kompilovaný program). Pokud si pamatuju, tyto knihovny se liší i aplikačním rozhraním, jenže hlavičkové soubory se jmenují stejně, a Debian je instaluje do týchž umístění.

Jinačí záludností je pojmenování samotných sdílených knihoven. Často vypadá název knihovny jako libknihovna.so.x.y.z, na níž vedou odkazy libknihovna.so.x a (pouze pro linkování zkompilovaných programů) libknihovna.so. Typicky x označuje verzi aplikačního binárního rozhraní (ABI), zatímco zbylá dvě čísla jen revizi kódu. Třeba knihovna jazyka C++ pro GCC 3.x < 3.4 byla libstdc++.so.5, zatímco od GCC 3.4 je libstdc++.so.6, a tyto dvě nejsou binárně kompatibilní, program je potřeba znova zkompilovat. (Z Windows se mi vybavuje třeba MSVCP50.DLL a MSVCP60.DLL.) Někdy je to ale horší, jméno knihovny může být mezi distribucemi úplně jiné (je tam třeba připsané nějaké další číslo verze), a aby program fungoval, je potřeba mu symbolickým odkazem dodělat onu vhodnou verzi.

Naštěstí to, co jsem popsal výš, jsou spíš extrémní případy, které nastávají typicky právě při aktualizaci systému, která ale v danou chvíli nejde dotáhnout do konce. Zase příklad – ke grafickému přihlášení chci dále využívat GDM 2.x, aktualizace nabízí GDM 3.x, které ale nechci. Některé knihovny nelze kvůli GDM 2.x odinstalovat, ty však stojí v cestě některým novějším knihovnám. Takové případy se řeší těžko, nelze jít ani kupředu, ani dozadu. V tomto vybraném případě dobře poslouží úkrok do strany – instalace jiného správce přihlášení, např. LightDM nebo LXDM.