RPM: Balíčkovací formát

RPM (původně zkratka pro Red Hat Package Manager, dnes rekurzivně RPM Package Manager) je nízkoúrovňový systém pro správu softwaru a zároveň standardizovaný formát souborů (s příponou .rpm). Byl vyvinut v roce 1997 společností Red Hat a stal se základním stavebním kamenem pro instalaci, aktualizaci a odstraňování softwaru v mnoha populárních linuxových distribucích, jako jsou Red Hat Enterprise Linux (RHEL), Fedora, CentOS, AlmaLinux, Rocky Linux nebo SUSE/openSUSE.

Hlavním cílem RPM je usnadnit distribuci zkompilovaného softwaru. Namísto toho, aby koncový uživatel musel ručně stahovat zdrojové kódy, řešit chybějící knihovny a software zdlouhavě kompilovat (tzv. Dependency Hell), obdrží jeden úhledný balíček. Ten obsahuje jak samotné binární soubory, tak i přesné instrukce, kam se mají v systému překopírovat.

Fyzický soubor s příponou `.rpm` není nic jiného než speciálně strukturovaný archiv. Skládá se ze čtyř hlavních logických částí:

• Lead (Hlavička souboru): Historická část, která slouží primárně k identifikaci souboru (tzv. magic number), aby operační systém bezpečně poznal, že se jedná o formát RPM. Dnes má spíše zpětně-kompatibilní význam.
• Signature (Digitální podpis): Zajišťuje integritu a bezpečnost. Obsahuje kryptografický hash (např. SHA-256) a GPG podpis tvůrce balíčku. Díky tomu systém pozná, že balíček nebyl po cestě zasažen hackerem nebo poškozen při stahování.
• Header (Metadatová hlavička): Zásadní datová část. Obsahuje podrobné informace o softwaru: název, verzi, architekturu (např. x86_64, ARM), jméno tvůrce, licenci, a především seznam závislostí (jaké další knihovny program potřebuje ke svému běhu).
• Payload (Užitečné zatížení): Samotná data. Jedná se o archiv ve formátu cpio, který je silně komprimován (historicky pomocí `gzip`, v moderních systémech nejčastěji pomocí `xz` nebo `zstd`). Obsahuje přesnou adresářovou strukturu a binární soubory aplikace.

Aby mohl vývojář vytvořit RPM balíček, musí napsat tzv. SPEC soubor (`.spec`). Jedná se o textový „recept“, který programu `rpmbuild` přesně říká, jak má stáhnout zdrojové kódy, jak je zkompilovat a jak je zabalit.

Typický SPEC soubor se dělí na několik fází:

• Předpříprava (`%prep`): Rozbalení stažených zdrojových kódů a aplikace případných patchů.
• Sestavení (`%build`): Samotná kompilace softwaru (často klasické spuštění `make`).
• Instalace (`%install`): Zkopírování zkompilovaných souborů do fiktivního dočasného kořenového adresáře (buildroot), který simuluje skutečný systém.
• Soubory (`%files`): Přesný soupis všech souborů, které si má RPM balíček „vzít“ a uložit do Payloadu.

Součástí SPEC souboru mohou být i skripty (Pre/Post install), které se automaticky spustí před nebo po instalaci balíčku (např. vytvoření nového systémového uživatele pro databázi nebo restartování webového serveru).

V praxi dochází k velmi častému zmatení mezi příkazy `rpm` a nástroji jako `yum`, `dnf` nebo `zypper`. Je klíčové chápat rozdíl mezi backendem a frontendem.

Nástroj `rpm` je nízkoúrovňový správce. Umí nainstalovat balíček, který už máte stažený fyzicky na disku (např. `rpm -i balicek.rpm`). Pokud ale zjistí, že balíčku chybí nějaká závislost (jiná knihovna), operaci zruší a vypíše chybové hlášení. Sám si chybějící knihovny stáhnout neumí, nemá přístup k internetovým repozitářům. Zapisuje provedené změny do lokální RPM databáze (uložené nejčastěji v `/var/lib/rpm/`).

Jedná se o vysokoúrovňové správce softwaru. Když jim řeknete, aby nainstalovaly program, připojí se na internet, prohledají repozitáře, stáhnou požadovaný RPM balíček a zároveň samy identifikují a stáhnou všechny chybějící závislosti. Samotnou fyzickou instalaci pak ale „pod kapotou“ tiše předají nízkoúrovňovému RPM.

Ve světě Linuxu existují dva hlavní konkurenční formáty. RPM (doména Red Hatu) a DEB (doména Debianu a Ubuntu).