Správce balíčků

(přesměrováno z Balíčkovací systém)

Správce balíčků je v informatice nástroj pro správu software nainstalovaného v počítači. Jednotlivé programy a aplikace jsou umístěny do speciálních souborů (tzv. softwarových balíčků), které je možné pomocí správce balíčků jednoduchým způsobem nainstalovat i odinstalovat. Správce balíčků obvykle umožňuje jednotlivé balíčky automaticky stahovat ze softwarových repozitářů umístěných na Internetu. Boom filozofie správců balíčků pochází z opensource linuxového (unixového – BSD) světa. Kde už od počátku (až na výjimky slackware) bylo základem distribuce software. Zbytek světa následoval: MSI (Microsoft Windows), App Store (Apple), Microsoft Store, GooglePlay (Google, Android) a podobně.

Synaptic Package Manager, GTK+ grafický front-end pro APT

Různí správci balíčků

editovat

Správce balíčků je obecný princip. Můžeme mít balíčkovací systém na úrovni operačního systému (uživatel instaluje aplikaci pro celý počítač a pro všechny uživatele, nebo jen pro jednoho uživatele); ale můžeme mít balíčkovací systém i v rámci vývoje aplikace, kdy vývojář využívá správce pro dodání knihoven potřebných pro jeho aplikaci (takzvaně spravování závislostí); a v neposlední řadě může být správcem balíčků nazýván systém pluginů v aplikaci, pomocí nichž uživatel rozšiřuje funkcionalitu dané aplikace. Existují i systémy s balíčky pro instalaci softwaru napříč celou sítí počítačů (Chef, Puppet, Salt, Ansible).

Správce balíčků je aplikace jako každá jiná. Někdy je rozšířená napříč několika operačními systémy (deb pro Linux, deb pro BSD), ale obvykle je spíše specifický pro daný operační systém nebo jeho konkrétní distribuci (např. různé distribuce Linuxu mají různé správce balíčků). V unixových operačních systémech jsou de facto standard. V systémech jako MacOS, či Microsoft Windows se postupně začínají prosazovat také.

Příklad typů balíčků a jejich správců pro operační systém
Pojmenování balíčku Pojmenování správce Výskyt
rpm yum, nově dnf Fedory, Red Hat Enterprise Linuxu, Centos
rpm URPMI Mandriva Linux
rpm YaST, ZYpp SUSE Linux
deb APT, dpkg, Aptitude, Synaptic Debian GNU/Linux, Ubuntu
.tar.xz pacman Arch Linux
port Ports BSD
portage Portage Gentoo Linux
homebrew brew MacOS
msi Microsoft Windows Installer Microsoft Windows

Kromě správců balíčků, které umožňují mít nainstalovánu pouze jednu verzi programu nebo sdílené knihovny, existují i instalační a balíčkovací systémy, které umožňují mít nainstalovány současně několik různých verzí programů a sdílených knihoven, např. Flatpak, Snappy, AppImage a Fedora Modularity.[1]

Příklad typů balíčků a jejich správců pro build aplikace
Pojmenování Výskyt, nástroj, jazyk
npm, yarn node.js, javascript
bower node.js, PHP
pip python
composer PHP
cabal Haskell
cargo Rust
lua-rocks Lua
Maven Java
Ivy Java

Příklad aplikací používající balíčky

Dostupnost

editovat

Programy pro správu balíčků jako dpkg existují nejméně od roku 1994.[2]

Linuxové distribuce zaměřené na binární balíčky jsou do značné míry závislé na systémech správy balíčků jako na primárním nástroji pro správu a údržbu softwaru. Mobilní operační systémy jako Android (založený na Linuxu), iOS (UN*Xové) a Windows Phone spoléhají téměř výhradně na obchod s aplikacemi a proto používají své vlastní systémy pro správu balíčků.

Srovnání s instalátory

editovat

Pro distribuci a instalaci softwaru se (zejména v prostředí Windows anebo pro distribuci uzavřeného softwaru) používají také specializované programy zvané instalátory. Od správců balíčků se liší v těchto ohledech:

Správce balíčků

Instalátor

Obvykle je součástí operačního systému. Každý produkt je dodáván s instalačním programem (instalátorem).
Používá jednu instalační databázi. Provádí vlastní instalaci, někdy zaznamenává informace o tomto zařízení v registru.
Může ověřovat a spravovat všechny balíčky v systému. Snadná instalace i mazání. Pracuje pouze s přibaleným produktem.
K dispozici systém repozitářů pro distribuci software. Produkt je třeba nějak získat – CD, Flashdisk, manuální stažení z internetu.
Jeden systém pro správu balíčků. Více instalačních dodavatelů.
Jeden formát balíčků. Více instalačních formátů.
Balíčky mohou na sobě záviset – sdílení Každá aplikace má vše svoje.
 
Ilustrace systému pro správu balíčků použitého ke stažení nového softwaru. Ruční akce mohou zahrnovat přijetí licenční smlouvy nebo výběr určité konfigurace specifické pro balíček.

Systémy pro správu balíčků mají za úkol organizovat všechny balíčky nainstalované v systému. Typickými funkcemi systému pro správu balíčků jsou:

  • Ověření kontrolního součtu souborů, aby byly zajištěny správnost a úplnost balíčku;
  • Ověření digitálních podpisů k ověření původu balíčku;
  • Použití archivačního programu na správu archivovaných souborů;
  • Aktualizace softwaru na nejnovější verze, typicky ze softwarového repozitáře;
  • Seskupení balíčků podle funkcí pro lepší orientaci uživatelů;
  • Správa závislostí, aby bylo zajištěno, že balíček je instalován včetně všech balíčků, které potřebuje. Tím se řeší problém známý jako dependency hell.

Některé další úkoly jsou splněny pouze několika systémy pro správy balíčků.

Problémy se sdílenými knihovnami

editovat

Počítačové systémy, které jsou založeny na propojení dynamických knihoven, namísto propojení statických knihoven, sdílí knihovny strojových instrukcí přes balíčky a aplikace. V těchto systémech jsou složité vztahy mezi různými balíčky, které vyžadují různé verze knihoven, což má za následek problém hovorově známý jako dependency hell. Na Microsoft Windows systémy, to je také nazýván DLL Hell při práci s dynamicky propojenými knihovnami. Dobrá správa balíčků je velmi důležitá v těchto systémech.[3]

Front-end na místě sestavených balíčků

editovat

Správce systému může instalovat a udržovat software pomocí jiných nástrojů než je software pro správu balíčků. Správce může například stáhnout zdrojové kódy nějakého programu, zkompilovat je a nainstalovat. Tím dojde k narušení synchronizace mezi informacemi v databázi se skutečným stavem systému. Následkem toho musí správce provádět dodatečná opatření, jako např. ruční řešení závislostí nebo začleňování změny do správce balíčků.

Existují nástroje, které umožňují, aby lokálně přeložený sestavené software byl začleněn do správu balíčků. Pro distribuce založené na balíčcích .deb a .rpm a pro Slackware Linux lze použít checkinstall. Pro systémy jako Gentoo Linux a pro hybridní systémy jako Arch Linux je možné napsat předpis, podle kterého se vytvoří balíček, který bude možné začlenit do lokální databáze balíčků.

Údržba konfigurace

editovat

Při aktualizacích softwaru jsou zvláště problematické aktualizace konfiguračních souborů. Vzhledem k tomu, systémy pro správu balíčků, alespoň v systémech UNIX vznikly jako rozšíření archivačních programů, mohou obvykle konfigurační soubory přepsat nebo nechat beze změny, místo jejich úpravy podle určitých pravidel. Výjimkami jsou obvykle soubory ke konfiguraci jádra (které, pokud by byly rozbité, by způsobili, že by počítač nemohl po restartu zavést operační systém). Obvykle dochází k problémům, pokud byl změněn formát konfiguračních souborů. Například pokud původní konfigurační soubor neobsahoval nějaký parametr, který musí být zakázán. Některé systémy pro správu balíčků, např. Debian s dpkg, umožňují konfiguraci během instalace. V jiných případech je žádoucí, nainstalovat balíčky s výchozím nastavením a tuto konfiguraci přepsat, např. při instalaci velkého množství počítačů bez grafické karty nebo zobrazovací jednotky. (Tento druh přednastavené instalace je také podporována dpkg).

Repozitáře

editovat
Související informace naleznete také v článku Repozitář.

Je-li třeba dát uživatelům větší kontrolu nad tím, jaké druhy softwaru mají být nainstalovány na jejich systému (a někdy také kvůli právním důvodům nebo pro pohodlí distributorů), balíčky se software bývají umístěny ve větším počtu repozitářů.[4]

Potlačení aktualizace

editovat

Když uživatel pracuje se softwarem pro správu balíčků, který přinese upgrade, je zvykem prezentovat uživateli se seznamem věcí, které je třeba udělat (obvykle seznam balíčků, které mají být aktualizovány, a případně dávat staré a nové číslo verze) a umožňují uživateli buď přijmout aktualizaci jako celek, nebo vybrat upgrade jen vybraných balíčků. Mnoho systémů pro správu balíčků lze nakonfigurovat tak, aby určité balíčky neaktualizovaly nikdy nebo pouze tehdy, když je v balíčku uvedeno, že předchozí verze obsahuje kritické zranitelnosti a nestability. Tento proces se někdy nazývá fixace verze.

Například:

  • yum podporuje tento se syntaxí exclude = openoffice *,[5]
  • pacman s IgnorePkg = openoffice[6] (zabrání aktualizaci openoffice v obou případech)
  • Dpkg a dselect má částečnou podporu příznaku hold ve výběru balíčků
  • APT rozšiřuje' příznak Hold na komplexní mechanismus „připínání“[7]
    • Uživatelé mohou také blacklistnout balíček[8]
  • aptitude má příznaky „hold“ a „forbid“
  • Portage podporuje tuto konfiguračním souboru package.mask

Kaskádové odstranění balíčků

editovat

Některé z pokročilejších funkcí správy balíčků nabízejí kaskádové odstranění balíčků,[6], při kterém jsou odstraněny i všechny balíčky, které jsou závislé na cílovém balíčku.

Běžné balíčkovací systémy a formáty

editovat

Univerzální správce balíčků

editovat

Univerzální správce balíčků, také označovaný za správce binárního repozitáře je nástroj, který optimalizuje stahování a ukládání binárních souborů, artefaktů a balíčků používaných a vytvářených při vývoji softwaru.[9] Cílem těchto správců balíčků je standardizovat způsob, jak firmy pracují se všemi typy balíčků. Umožňují uživatelům možnost aplikovat bezpečnostní metriky a zajistit shodu s požadavky pro všechny typy artefaktů. Univerzální správci balíčků bývají centrem řetězce nástrojů pro vývoj a údržbu softwaru[10]

Formáty balíčků

editovat
Související informace naleznete také v článcích Softwarový balíček (instalace) a Archivní soubor.

Každý správce balíčků je závislý na formátu a metadatech balíčků které správcuje. To znamená, že balíčkovací systém musí seskupovat soubory, které mají být začleněny pro konkrétní správce balíčků spolu s příslušnými metadaty, jako například závislosti. Často základní sada nástrojů spravuje základní instalace těchto balíčků a různých správců balíčků používají tyto nástroje k poskytnutí dalších funkcí.

Například yum používá rpm jako backend. Yum rozšiřuje funkčnost backend přidáním funkce jako jednoduchou konfiguraci pro udržení sítě systémů. Dalším příkladem je Synaptic Package Manager, který poskytuje grafické uživatelské rozhraní používající knihovnu Advanced Packaging Tool (apt), která zase závisí na dpkg pro základní funkčnost.

Program Alien je určen k převodu balíčků mezi různými formáty, pokud, co se týče organizace souborového systému, odpovídají specifikaci Linux Standard Base. Podporuje formáty RPM, .deb, Stampede (.SLP) a Slackware (tgz a .TXZ).

Open source software systémy a software zadarmo

editovat

Vzhledem k povaze free a open source software jsou balíčky s podobnými a slučitelnými licencemi k dispozici pro použití na řadě operačních systémů. Tyto balíčky lze kombinovat a distribuovat pomocí konfigurovatelných a vnitřně komplexních balíčkovacích systémů, které zvládají zpracovávat mnoho permutací softwaru a vypořádat se se závislosti a konflikty závislými na verzích softwaru. Některé systémy balení pro free a open source software jsou také samy uvolněny jako free a open source software. Jedním z typických rozdílů mezi správu balíčků v proprietárních operačních systémech, jako je Mac OS X a Windows, a systémů free a open source software, jako je Linux, který je zdarma, je že open source software systémy umožňují instalaci a aktualizaci balíčků třetích stran jednotným mechanismem, zatímco systémy pro správu balíčků z Mac OS X a Windows umožňují aktualizovat pouze software dodaný společností Apple nebo Microsoft (a některé ovladače třetích stran v systému Windows). Schopnost průběžně aktualizovat software třetích stran se obvykle řeší přidáním URL odpovídajícího úložiště do konfiguračního souboru správce balíčků.

Specializovaní správci balíčků

editovat

Vedle správců aplikací na úrovni operačního systému existují i správci balíčků pro operační systémy s omezenými schopnostmi a pro programovací jazyky, pro které vývojáři potřebují poslední verze knihoven.

Na rozdíl od systémů pro správu balíčků na úrovni systému se tyto systémy zaměřují pouze na malou část systému; obvykle sídlí v nějakém adresářovém podstromě, který není spravován hlavním správcem balíčků jako c:\cygwin nebo /usr/local/fink. Problém je se správci balíčků, které pracují s knihovnami, což může vést ke konfliktům mezi oběma správci balíčků, když si oba myslí, že vlastní určitý soubor, a mohou rozbíjet proces upgradu.

V užším významu se správci balíčků vyskytují i v prostředí programovacích jazyků. V balíčcích se však typicky distribuují pouze softwarové knihovny a samotný pojem „balíček“ (package) se používá právě pro označení knihoven (například v jazyce Java[11]). Přehled správců balíčků pro různé programovací jazyky obsahuje článek softwarový repozitář.

Jako správce balíčků pro Wine (aplikační vrstva pro běh softwaru z Windows na unixových systémech) se chová také program Winetricks[12]. Ten usnadňuje instalaci součástí původně určených pro Windows (knihoven, fontů) v rámci adresáře (zvaného „prefix“), v němž Wine vytváří prostředí podobné Windows.

Společným rysem těchto správců balíčků je to, že spravují pouze vymezenou část systému. Winetricks zasahuje (s právy uživatele) pouze do izolovaného prostředí jedné virtuální „instalace“ Windows a správci softwarových knihoven se starají o samostatný adresář s knihovnami daného programovacího jazyka (například /usr/lib/python3.5/site-packages v případě Pythonu). Takový adresář ale bývá zároveň ve správě systémového správce balíčků a proto kvůli současnému používání obou správců může docházet k různým kolizím (například odstranění balíčku specializovaným správcem bez vědomí systémového správce).

Ian Murdock poznamenal, že správa balíčků je „tím největším pokrokem, co Linux přinesl průmyslu“, že stírá hranice mezi operačním systémem a aplikací, a že „zjednodušuje protlačuje nové inovace [...] na trh a [...] vyvíjí operační systém“.[13]

Reference

editovat

V tomto článku byl použit překlad textu z článku Package manager na anglické Wikipedii.

  1. David Ježek: Flatpak, Snap, Modularity: počátek konce éry balíčkovacích systémů?, 2. 11. 2018, https://www.root.cz/clanky/flatpak-snap-modularity-pocatek-konce-ery-balickovacich-systemu/
  2. dpkg version 0.93.15 source code [online]. Dostupné v archivu pořízeném z originálu dne 2015-04-02. 
  3. CHRIS, Tucker. Optimal Package Install/Uninstall Manager. cseweb.ucsd.edu. UC San Diego, 2007-03-15, s. 1. Dostupné online [cit. 2011-09-14]. 
  4. Linux repository classification schemes [online]. braintickle.blogspot.com [cit. 2008-03-01]. Dostupné online. 
  5. CentOS yum pinning rpms [online]. centos.org [cit. 2008-03-01]. Dostupné v archivu pořízeném dne 2007-11-02. 
  6. a b pacman(8) Manual Page [online]. archlinux.org [cit. 2008-03-01]. Dostupné online. 
  7. How to keep specific versions of packages installed (complex) [online]. debian.org [cit. 2008-03-01]. Dostupné v archivu pořízeném dne 2006-06-13. 
  8. Apt pinning to blacklist a package [online]. [cit. 2010-08-19]. Dostupné v archivu pořízeném dne 2011-07-22. 
  9. WATERS, John K. JFrog Releases 'Universal' Artifact Repository [online]. Application Development Trends Magazine, 8 September 2015. Dostupné online. 
  10. DECOSTER, Xavier. An Overview of the NuGet Ecosystem [online]. 18 August 2013. Dostupné online. 
  11. SEMECKÝ, Jiří. Naučte se Javu – balíčky. Interval.cz [online]. 2002-10-01 [cit. 2016-09-23]. Dostupné online. 
  12. VRÁTIL, Dan. Wine a jeho pomocníci. AbcLinuxu.cz [online]. 2009-11-19 [cit. 2016-09-23]. Dostupné online. 
  13. How package management changed everything [online]. ianmurdock.com [cit. 2008-03-01]. Dostupné v archivu pořízeném dne 2009-02-23. 

Související články

editovat

Externí odkazy

editovat