Balíček, repozitář, závislost, správce balíčků
Toto jsou pojmy, které – předpokládám – dobře znáte, tudíž je prolétnu jen letem světem. Balíček je obecně komponenta. Může to být aplikace, ale také dokumentace, datové soubory, sada ikon, fontů či tapet, knihovna atd. Jelikož balíčky mají atomický charakter (obsahují „jedno kolečko v soukolí“), existují mezi nimi závislostní vazby, tj. jeden balíček pro svou funkci může vyžadovat další balíčky, a ty mohou vyžadovat další balíčky atd.
Balíčky jsou uloženy v repozitářích. To jsou jednoduše skladiště balíčků. Mohou mít podobu adresáře, síťového serveru, instalačního média atd. Nejčastěji se používají síťová úložiště.
Software je v linuxových distribucích spravován centrálně, prostřednictvím správce balíčků, který bere v úvahu závislosti, ví, co je dostupné v repozitářích a de facto provádí téměř vše za správce. Ten mu jen řekne, co chce instalovat, odinstalovat či aktualizovat, a správce balíčků to provede.
Kompilace
Software pro Linux, alespoň ten svobodný a open-source, je obvykle k dispozici v podobě zdrojového kódu (člověkem čitelné podoby programu). Ten je v případě řady programovacích jazyků nutné převést do podoby, kterou je schopen zpracovat procesor, tedy do strojového kódu. Ten pak můžete spustit a využívat.
V případě většiny linuxových distribucí tento proces již někdo provedl a do repozitářů umístil příslušný balíček se strojovým kódem (někdy také „binárkou“), který stačí nainstalovat a je připraven k použití.
Distribuce a software
Centralizovaná správa softwaru, tedy správa softwaru pomocí správce balíčků, je považována za jednu ze silných stránek GNU/Linuxu. Má ovšem z pohledu správce serverů dvě nevýhody. V první řadě, ne všechen software dostupný pro GNU/Linux je v distribučních repozitářích a ne vždy je to proto, že by daná věc nebyla zajímavá či užitečná. Abych nezůstával příliš v teoretických rovinách, uvedu malý příklad. Debian (a řada dalších distribucí) neobsahuje jádra patchovaná pomocí grsecurity. Zřejmě proto, že se dosud nenašel dobrovolník, který by jádra připravoval a udržoval.
Řada distribucí, včetně Debianu, stojí na ryze komunitním vývoji. O konkrétní balíčky se starají konkrétní lidé (říká se jim maintainer), kteří jsou zodpovědní za jejich tvorbu i údržbu. Někdy se stane, že nějaký balíček z repozitářů vypadne, nebo nebude začleněn, protože to představuje hodně práce a nikomu se do toho nechce. U podnikových distribucí, kde není problém na „nechtěnou“ práci někoho najmout, je zase typické, že jejich repozitáře obsahují méně softwaru než jejich ryze komunitní kolegové.
Druhým bodem, který lze vnímat v závislosti na úhlu pohledu jako výhodu i jako nevýhodu, je zmrazení verzí. Když distribuce s klasickým modelem vývoje vydá nové vydání, v repozitářích zpravidla zůstanou jednotlivé komponenty ve stejných verzích po celou dobu podpory daného vydání. Je-li v nějakém balíčku nalezena chyba, která byla opravena v nové verzi dané komponenty, provede se tzv. backport příslušné změny, tj. změna se aplikuje na starší verzi komponenty, která je dostupná v repozitářích. Do repozitářů se tedy nedostávají novější verze komponent, a ty samozřejmě časem zastarávají.
Tento systém má svůj dobrý důvod – nové verze komponent obsahují změny, které nemusí být vždy zpětně kompatibilní. U serverového softwaru se může měnit syntax konfiguračních souborů i chování samotných démonů, čímž může vzniknout jak potenciální bezpečnostní zranitelnost, tak nepříjemný stav, kdy se po aktualizaci démon odmítne znovu spustit. Nehledě na to, že nové verze obsahují zpravidla kromě nových zajímavých vlastností i nové chyby.
Dlužno dodat, že tento problém se netýká distribucí, které používají tzv. rolling release model vývoje (Arch Linux, Gentoo, Source Mage GNU/Linux apod.), kde se nové verze (po otestování) rovnou zařazují do hlavních repozitářů, a distribuce jsou tak vlastně ve stádiu neustálého vývoje. Tyto distribuce obecně nebývají doporučovány pro produkční servery, i když jsou na některých používány. Jistě, záleží v první řadě na tom, co a jak má na serveru běžet a která distribuce je pro to nejvhodnější (nehledě na to, že velkou roli hraje i to, kterou distribuci správce dobře ovládá).
Úskalí kompilace
Balíčkovací systém šetří (nejen) správcům práci. Umožňuje snadnou instalaci, odinstalaci i aktualizaci softwaru. Aktualizace se týká veškerého softwaru dostupného z repozitářů (pokud distribuce nestanoví jinak). Ve chvíli, kdy se pustíte do kompilace, o tyto výhody přijdete. Pokud si nesestavíte vlastní balíček obsahující vámi zkompilovaný software, nebude moci brát balíčkovací systém v úvahu soubory, které tomuto softwaru v souborovému systému patří - odinstalování tedy může být problematické. Ale i když si vlastní balíček postavíte a nainstalujete jej přes správce balíčků, zůstane na vás stále to nejdůležitější - jeho aktualizace.
Závislosti
Samotná kompilace není jednoduchá. Nejenom, že potřebujete kompilátory a příslušné nástroje, ale musíte také vyřešit závislostní vazby. Je možné, že váš software vyžaduje knihovny nebo komponenty, které v systému nemáte. Ty je pak třeba buď doinstalovat z repozitářů, nebo také zkompilovat.
Změny v knihovnách
Aktualizovat balíček byste měli nejenom, když vyjde jeho nová verze, ale také, pokud se zásadně změní verze závislých knihoven. Tohle je ale naštěstí spíše problém rolling release distribucí, jelikož v klasických zůstanou knihovny zpravidla ve stejných verzích. Může ale nastat problém při povýšení distribuce. V rolling release distribucích je třeba překompilovávat častěji, neboť tam se verze knihoven čas od času mění.
Alternativy
Ideální je, pokud jste schopni pracovat se softwarem, který je v distribučních repozitářích, byť někdy musíte překousnout, že nová verze, už třeba půl roku dostupná, umí něco nového, co by vám usnadnilo práci. Ale ideální situace nenastane vždy – proto se někdy kompilaci nevyhnete. Ovšem ještě před tím, než se do kompilace pustíte, by bylo vhodné zvážit možná alternativní řešení.
Debian backports
Jelikož se tento seriál zaměřuje na distribuci Debian, nelze nezmínit nyní již oficiální projekt Debian backports. Tento projekt tvoří repozitář, který lze zkombinovat se standardními repozitáři Debianu, a získat tak možnost instalace vybraného novějšího softwaru, který byl zkompilován pro stabilní vydání. Kupříkladu, kdybyste nebyli spokojeni s Postgresem 8.4 v Debianu Squeeze a chtěli Postgresql 9.0, který nedávno vyšel, nemuseli byste sáhnout ke kompilaci – stačilo by vám použít backporty, ze kterých byste verzi 9.0 nainstalovali.
Neoficiální repozitáře
Řada projektů má k dispozici neoficiální repozitáře (neoficiální z pohledu Debianu), které můžete použít k získání aktuální verze ve stabilním vydání. Kupříkladu, zde v seriálu zmíněný Jabber/XMPP server Prosody má k dispozici neoficiální repozitář, kde najdete vždy aktuální verzi.
Strategie
Jelikož kompilace není jednoduchá a má svá úskalí, bývá dobré se jí vyhnout, pokud můžete. Zde mohou pomoci výše zmíněné alternativy. Pokud se pro kompilaci rozhodnete, musíte zvážit jednak dopad na „pohodlnost“ správy, respektive na nové povinnosti a možná úskalí, ale také na možné bezpečnostní dopady (síťová služba, SUID root popřípadě pod rootem běžící atd.). Řada projektů má k dispozici e-mailové konference s bezpečnostními hlášeními nebo hlášeními o nových verzích. Doporučuji se do nich přihlásit a pravidelně číst poštu, abyste mohli reagovat na případný bezpečnostní problém nebo věděli o dostupnosti nové verze.
Tím bych tento díl ukončil. Příště vám kompilaci představím po praktické stránce.
