tučňák
Vybrat další barevné schéma
VýchozíZelenýModrýČernýZlatý
opona
opona

google


Správa balíků softwaru - RedHat Package Manager

Co je balík softwaru?

Při instalaci jakéhokoli většího softwarového systému - ať už je to operační systém (jako je třeba Linux) nebo aplikace (jako například WordPerfect) - asi každý zjistil, že tento systém je distribuován v určitých oddělených kouscích - balících (packages). Takovýto balík na instalačním médiu obvykle slouží k vygenerování jednoho nebo více souborů v příslušné části disku.

Takže pod pojmem balík softwaru (package) si lze představit několik souvisejících souborů zabalených do nějaké formy, kterou lze dále distribuovat a na cílovém stroji rozbalovat. A právě instalace - rozbalování - balíků je jednou z hlavních úloh správce balíků (package manageru).

Většina čtenářů tohoto listu již asi slyšela o distribucích Debian a Red Hat. V oznámeních o těchto distribucích se dočtete, že používají určitý sofistikovaný systém správy balíků. Co to je a proč nestačí distribuovat software jako tar.gz soubor se dočtete v tomto článku.

Správce balíků

Ne všechny operační systémy (nebo lépe distribuce) mají svůj vlastní definovaný formát pro správu balíků, natož pak svého vlastního správce balíků. Například pod DOSem jsou programy distribuovány například jako samorozbalující se (.EXE) nebo komprimovány programem ZIP nebo ARJ.

Některé systémy sice mají správce balíků, ale ve formě příslušných balíků je distribuován pouze operační systém samotný, nikoli však další programy od jiných výrobců. To je případ většiny komerčních UNIXů, uveďme například inst na IRIXu.

A jiné systémy správy balíků zase nemají všechny vlastnosti, které lze čekat od opravdového systému pro správu balíků (to je například případ Windows).

Vyvstává tedy otázka, co všechno lze čekat od systému pro správu balíků.

Co může umět správce balíků?

Samozřejmě první a základní vlastností je, že musí umět příslušný balík rozbalit a nainstalovat. Tomuto v podstatě vyhovují i balíky distribuované ve formátu .tar.gz a tar s gzipem ve funkci správce balíků.

Podstatnou úlohou pro správce balíku je odinstalování softwaru. Jistě znáte případy z prostředí Windows, kdy odinstalovaný program po sobě zanechá spousty DLL souborů, volně rozprostřených po celém disku, o dočasných souborech ani nemluvě. Dobrý správce balíků by měl být schopen balík odinstalovat, a to nejen smazáním všech souborů, které k balíku patří, ale i zrušením odkazů z dalších konfiguračních souborů, zrušením příslušných pseudouživatelů ze systémových tabulek, adresářů pro dočasné soubory a podobně. To jest po odinstalování balíku by měl systém být ve stavu, v jakém byl před jeho nainstalováním.

Jistě se vám už někdy stalo, že jste narazili na svém disku na nějaký soubor, o němž jste si vůbec nebyli jisti, k čemu vlastně slouží. Toto by měla být další schopnost správce balíků - udržovat v nějaké rychle vyhledávatelné formě informace o tom, které balíky jsou v systému nainstalovány a které soubory patří do kterého balíku. Tohle už například Windows nezvládají.

Správce balíků by si nejen měl pamatovat, které soubory k danému balíku patří, ale také na požádání zkontrolovat, jestli tyto soubory jsou skutečně v takovém stavu, v jakém byly při konfiguraci. Správce balíků má udržovat mimo jiné i informace o přístupových právech jednotlivých souborů, jejich vlastnících a skupinách. Navíc je dobré, pokud si správce balíků pamatuje i kontrolní součet souborů (obvykle pomocí metody MD5).

Pokud instalujete na svůj počítač cizí software, měli byste také mít možnost přesvědčit se, že balík nebyl cestou modifikován. K tomu slouží mimo jiné kontrolní součet celého balíku. Také lze ověřovat, je-li balík skutečně vyroben tím, o kom to tvrdí. K tomu slouží elektronický podpis balíku, obvykle metodou RSA (PGP).

Často se setkáte s nutností upgradovat určitý balík softwaru.Na některých systémech vám nezbude než smazat původní balik a nainstalovat nový. Tímto ovšem obvykle ztratíte příslušné konfigurační soubory. Správce balíků by měl být schopen upgradovat balík s tím, že vás upozorní, které konfigurační soubory jste měnili a které ne. Pochopitelně by měl konfigurační soubor přepsat novou verzí a starý někam uložit, byl-li modifikován. Stává se totiž, že nová verze softwaru vyžaduje jiný formát konfiguračního souboru, než byl u starší verze.

Instalace softwaru není ovšem jen rozbalení balíku. Často je třeba přidat určité informace do různých souborů (/etc/passwd, /etc/inetd.conf a podobně). Tento úkol je netriviální a je to jedna z příčin existence konfiguračních adresářů místo konfiguračních souborů (/etc/cron.daily, /etc/profile.d, /etc/rc.d, /etc/pam.d a další). Přesto je někdy nutno změnit konfigurační soubor programem. Dobrý správce balíků/formát balíků by měl umět spustit skript uložený uvnitř balíku, a to před instalací, po instalaci, před smazáním a po smazání určitého balíku.

Někdy je také nutné, aby před nainstalováním určitého balíku byl nainstalován jiný balík (říkáme, že balík závisí na jiném balíku). Toto se typicky vyskytuje například u knihoven - příslušná sdílená knihovna musí být nainstalována před instalací programu, který ji používá. Stává se také, že balík nevyžaduje instalaci jiného konkrétního balíku, ale balíku, obsahujícího určitý soubor (například program mail může vyžadovat existenci souboru /usr/sbin/sendmail , nebo program v Perlu vyžaduje předchozí nainstalování Perlu samotného). Další důležitou vlastností správce balíku jsou tedy závislosti (dependencies).

Pro psaní obslužných programů pro správu balíků se také vyžaduje, aby byl formát balíku dobře dokumentován, navržen rozšiřitelně pro přidání dalších vlastností (s tím souvisí i umožnění dalšího vývoje formou verze příslušného formátu balíků). Vývoj aplikací a nadstaveb na správu balíků jistě usnadní i dostupnost knihovny pro práci s balíky a s databází instalovaných balíků.

Správce balíků musí také napomáhat vytváření balíků někým jiným, než autorem distribuce nebo operačního systému. Musí být schopen distribuovat i balíky ve zdrojové podobě včetně případných záplat. V balíku ve zdrojové formě musí být obsaženy všechny informace k automatickému skompilování a nainstalování balíku z původní nemodifikované zdrojové verze daného softwaru. To jest v balíku by měl být původní nemodifikovaný zdrojový text sám (například ve formě tar.gz souboru), záplaty pro případný port na danou platformu, příkazy pro rozbalení, kompilaci a nainstalování, a samozřejmě seznam souborů, které v konečné fázi budou ke kompilovanému balíku patřit.

Poslední, i když ne nejméně důležitou vlastností správce balíků je, aby samotný software pro správu balíků byl volně šiřitelný. Tato vlastnost je důležitá u jakéhokoli softwaru stejně jako u správce balíků softwaru.

Správci balíků v Linuxu

V distribucích Linuxu se postupem času vyvinuly prostředky pro správu balíků, a to v nejrůznějších formách a schopnostech. Správce pkgtool z distribuce Slackware má poměrně omezené možnosti. Udržuje informace o jménech souborů v jednotlivých balících (a tedy umožňuje jistou formu odinstalování balíku), umí i spustit skript po instalaci. Jeho kladnou vlastností je formát balíku - jedná se o běžný tar.gz soubor, který tedy lze prohlížet a rozbalovat i na jiných než Linuxových systémech.

Mezi další patří dpkg z distribuce Debian. Je to první správce balíků, který umí i závislosti (dependence). Distribuce Red Hat používá systém RPM, o kterém bude v tomto listě řeč v příštích číslech. Oba dva systémy tvoří špičku ve správě balíků. Liší se v některých drobnostech s tím, že postupně přebírají i kladné vlastnosti ze svých protějšků: do RPM byly implementovány závislosti, do dpkg zase MD5 součty a PGP podpisy.

Před nějakou dobou se objevil program alien, který umožní instalovat balíky z Red Hatu, Debianu a Slackwaru i do libovolné z těchto distribucí.

V příštím čísle Linuxových novin porovnáme dpkg a RPM.


Úvod do RPM

V předchozím čísle jsem se věnoval problematice balíků softwaru obecně a informacím o tom, co by správce balíků měl umět. V tomto čísle se podrobněji podíváme na systém RPM (RedHat Package Manager) z Red Hat Linuxu.

Současný systém RPM je výsledkem dlouhého vývoje. Je založen na starších systémech Red Hat Softwaru, jako je RPP a PM, a také na správci balíků PMS, použitého v distribuci BOGUS blahé paměti. První verze RPM byly psány v Perlu a nepodporovaly více architektur. Použití Perlu také komplikovalo nasazení RPM v omezeném prostředí, jako jsou například bootovací diskety při instalaci systému.

V současné době se používá RPM verze 2, což je systém psaný v jazyce C, přenositelný (a také přenesený) na nejrůznější architektury, s dostatečně rychlým a robustním designem databáze. Formát databáze i RPM balíků je navržen rozšiřitelně, lze tedy přidávat nové vlastnosti. V poslední době to například byly závislosti mezi balíky nebo balíky nezávislé na architektuře (to jsou ty, které neobsahují žádné binární programy závislé na architektuře; příkladem je balík ghostscript-fonts nebo howto).

Cíle návrhu RPM

  • Jednoduché instalování a rušení balíků

    Preinstalační a post-instalační skripty dávají autorovi balíku kompletní kontrolu nad tím, jak se balík bude instalovat (například qmail přidává určité uživatele do /etc/passwd, ssh může při instalaci vygenerovat RSA pár klíčů a podobně). Totéž platí pro skripty před a po odinstalování balíku. Je-li balík navržen správně, může pro svoji instalaci i odinstalování učinit vše potřebné.

  • Kontrola instalovaných balíků

    Správce balíků umí nejen zjistit, které soubory patřící danému balíku se změnily, ale umí také například vyvolat verifikační skript, který umožní například zkontrolovat syntaxi konfiguračních souborů.

  • Jednoduchá tvorba balíků

    Tvorba a údržba balíků v RPM není o mnoho složitější, než kompilování a instalace ze zdrojových textů. Pokud se tato instalace provádí na více počítačích, nebo dokonce chcete čas od času instalovat novější verzi daného softwaru, RPM značně šetří čas: ve zdrojovém RPM balíku je totiž poznamenáno, jaké všechny úpravy autor dělal na původní zdrojové distribuci softwaru, než vznikla kompilace a později i běhu schopná instalace.

  • Práce na více architekturách

    RPM zamezí duplikaci práce při kompilování a používání téhož softwaru na více architekturách. Pokud je kompilace nebo instalace balíku na jiné platformě odlišná od původní platformy, má RPM možnost ve zdrojovém balíku uvádět příkazy, které se provedou jen na určitých architekturách.

Uvnitř RPM balíku

Nebudu zde popisovat přesně definici struktury RPM souboru, ale přesto stojí za to alespoň rámcově vědět, co všechno RPM balík obsahuje.

  • Jméno balíku

    Tato položka je zde proto, aby bylo možné RPM soubory ukládat i na svazcích, které nepodporují dostatečně dlouhá jména souborů (jako například FAT nebo Minix FS). Jako příklad jména si uveďme třeba ssh-1.2.21-1i.i386.rpm.

    Jméno balíku se obvykle skládá z těchto komponent:

    • Jméno softwaru(zde: ssh).

      Odpovídá názvu programu nebo programového systému, který je obsažen v daném balíku nebo souhrnně pojmenovává soubory v tomto balíku (třeba XFree86-100dpi-fonts).

    • Verze softwaru(zde: 1.2.21).

      Identifikuje verzi programu, který je uvnitř daného balíku.

    • Verze balíku(package release; zde: 1i).

      Odpovídá zhruba tomu, kolikrát byl balík znovu zabalen s různými modifikacemi a úpravami a zveřejněn.

      Pokud se například najde chyba v post-instalačním skriptu, může autor balíku vydat nový release balíku.

    • Architektura(zde: i386).

      Specifikuje, pro kterou

      platformu je balík určen. Navíc poslední verze RPM podporují speciální architekturu noarch, která značí, že balík lze instalovat na libovolné platformě (například již zmiňovaný balík ghostscript-fonts). V RPM balíku je kromě hardwarové architektury ještě uveden operační systém, pro který je balík určen. Tento atribut se ale neprojeví v názvu balíku.

  • Informace o balíku jako celku:
    • datum a čas vytvoření balíku.
    • datum a čas instalace balíku, jedná-li se o již nainstalovaný balík.
    • celková velikost všech souborů v balíku.
    • jméno stroje, na kterém byl balík vytvořen.
    • jméno člověka nebo firmy, která balík distribuuje.
    • jméno distribuce, ke které balík patří.
    • skupina softwaru, do které balík náleží (například balík ssh patří do skupiny Applications/Networking). Seznam skupin a podskupin zveřejňuje Red Hat Software. Skupina se používá k tomu, aby uživatel byl schopen procházet balíky tematicky patřící k sobě.
    • MD5 kontrolní součet celého balíku.
    • libovolný (i nulový) počet digitálních PGP podpisů. Tyto podpisy slouží k ověření autora balíku. Balíky distribuované Red Hat Software jsou podepsány jedním PGP klíčem, takže je možné je zkontrolovat. PGP klíč softwaru naleznete na
      ftp://ftp.fi.muni.cz/pub/linux/distributions/
      redhat/redhat-5.0/i386/RPM-PGP-KEY
    • popis balíku - jednořádková informace o balíku (summary) a jednak libovolně dlouhý popis (description).
    • instalační a verifikační scripty.
  • Informace o jednotlivých souborech:
    • jméno souboru s cestou
    • obsah souboru
    • přístupová práva
    • vlastník a skupina souboru
    • MD5 kontrolní součet každého souboru

V příštím čísle se budeme věnovat jednotlivým parametrům programu RPM pro instalaci, rušení a upgradování balíků a pro získávání informací o balících.


Instalujeme balíky ve formátu RPM

V minulém čísle Linuxových novin jsem popsal RPM balík, jeho části a informace, které jsou v tomto balíku uvedeny o jeho jednotlivých souborech. Dnešní část je zaměřena na instalaci RPM souborů do systému.

Prvním předpokladem instalace balíku je mít tento balík k dispozici v RPM formátu pro danou architekturu (nebo noarch balík pro libovolnou architekturu). RPM balík je možno mít na pevném disku nebo na vzdáleném FTP serveru.

Cesta k balíku je jedním z parametrů příkazu rpm. Je možno uvést buďto cestu do souborového systému (absolutní nebo relativní), nebo URL pro přístup přes FTP:

  • /cdrom/RedHat/RPMS
    /ssh-1.2.21-1i.i386.rpm
  • ftp://ftp.redhat.com/pub/redhat
    /contrib/i386/squid-1.NOVM.18-5.i386.rpm

Pokud je balík z neznámého zdroje, je dobré před jeho instalací zkontrolovat signaturu. K tomu je potřeba systému RPM sdělit, kde máme uloženy svoje svazky klíčů pro PGP. Do souboru /etc/rpmrc vložíme řádek podobný následujícímu:

   pgp_path:       /home/kas/.pgp

Ve svazku veřejných klíčů musíme pochopitelně mít veřejný klíč autora balíku. U balíků patřících k distribuci je to jednoduché - veřejný klíč Red Hat Software je na každém distribučním CD nebo na mirrorech. Je-li balík vyroben někým jiným, je nutno si veřejný PGP klíč obstarat jinak.

Kontrolu všech signatur v RPM balíku provedeme následujícím příkazem:

   $ rpm --checksig <balík>.rpm
   <balík>.rpm: size pgp md5 OK

Výstup znamená, že balík má správnou velikost i MD5 součet a že souhlasí i PGP podpis.

Instalace balíků

Balík ve formátu RPM instalujeme pomocí programu rpm s přepínačem -i. Instalace probíhá v několika krocích:

Kontrola závislostí

- některé balíky vyžadují ke své činnosti, aby v systému byly přítomny jiné balíky (například poštovní klient může vyžadovat program /usr/sbin/sendmail, program v X11 může chtít svoje dynamicky linkované knihovny a podobně). Kontrola závislostí také ověří, jestli balík nezpůsobí problémy jinému již nainstalovanému balíku (například v systému smí být pouze jeden program pro doručování pošty jako je sendmail nebo qmail).

Kontrola konfliktů

- není například možné nainstalovat tentýž balík ještě jednou, nebo instalovat balík starší verze, než v systému právě je (toto lze obejít, pokud skutečně chceme nainstalovat starší verzi). Nelze také instalovat balík, který by přepsal soubory patřící jinému balíku.

Ošetření výskytu konfiguračních souborů

- je-li v systému již přítomen konfigurační soubor nějakého programu (například nainstalovaného mimo systém RPM), instalační program se snaží takovýto soubor zachovat. Přesná pravidla pro nakládání s verzemi konfiguračních souborů popíšeme, až budeme hovořit o upgradech - instalacích novějších verzí balíků.

Spuštění preinstalačního scriptu
Rozbalení souborů, obsažených v balíku
Spuštění postinstalačního scriptu
Uložení informací

o nainstalovaném balíku do databáze RPM

Další možnosti

K vlastní instalaci (přepínač -i) lze specifikovat i další podrobnější volby:

-v

- podrobnější výpis o průběhu instalace.

-vv

- ještě podrobnější výpis. Zobrazuje i informace o průběhu instalace jednotlivých souborů.

-h

- zobrazuje znaky #, které ukazují, jak postupuje instalace.

--percent

- zobrazuje v procentech informaci o postupu instalace balíku. Výstup z rpm s tímto přepínačem je určen pro grafické programy, které pak mohou zobrazovat na základě tohoto výstupu například progress-bar.

Průběh instalace lze modifikovat následujícími přepínači:

--test

- neprovede žádné akce, pouze kontroluje, jestli lze balík nainstalovat (tj. není-li konfliktní nebo nevyžaduje-li ještě nějaký další balík).

--replacepkgs

- provede instalaci, i když je balík již nainstalován. Je vhodné zejména v případě, kdy dojde nějakým způsobem k poškození původně nainstalovaných souborů a chceme balík prostě "přeinstalovat".

--replacefiles

- přepíše soubory, které jsou obsaženy ještě v jiném balíku. Použije se v případě, kdy nový balík obsahuje tentýž soubor jako některý již nainstalovaný balík, a když chceme RPM přinutit přesto nový balík nainstalovat.

--nodeps

Neprovádí kontrolu závislostí mezi balíky. Lze použít, pokud chceme například používat jen určitou část balíku (například v balíku ssh-clients je program ssh-add, který potřebuje knihovny X11; chceme-li nainstalovat ssh-clients na stroji, kde X11 knihovny nejsou, můžeme použít --nodeps s tím, že nebude možno spustit program ssh-add).

--force

- tento přepínač je zkratkou za --replacepkgs a --replacefiles.

--excludedocs

- nainstaluje balík bez dokumentace. Nepotřebujeme-li dokumentaci, můžeme nainstalovat balík bez souborů, které v něm byly označeny jako dokumentační. Typicky jsou to manuálové stránky a soubory v adresáři /usr/doc.

--includedocs

- opak předchozího. Je-li v /etc/rpmrc zakázáno instalovat dokumentační soubory, můžeme tímto přepínačem specifikovat, že pro tento konkrétní RPM balík se má dokumentace nainstalovat.

--noscripts

- nainstaluje balík, aniž by se spustily příslušné preinstalační a postinstalační scripty.

--ignorearch

- nainstaluje balík i přesto, že byl původně určen pro jinou architekturu.

--ignoreos

- nainstaluje balík, původně určený pro jiný operační systém.

--ftpproxy, --ftpport

- umožní specifikovat adresu a port FTP proxy serveru. Použije se při instalaci balíků z FTP, je-li počítač oddělen od FTP serveru proxy serverem.

--prefix <cesta>

- instaluje relokovatelný balík. Relokovatelný balík je takový, který může být nainstalovaný do libovolné adresářové struktury. Správce systému se pak může rozhodnout, kam balík nainstalovat. Jedna z tradičních možností je /usr/local, jiná možnost je například /opt, pro pokusnou instalaci můžeme zvolit /tmp/<balík>.

--rcfile <soubor>

- určí alternativní cestu ke konfiguračnímu souboru (implicitní je /etc/rpmrc). Z konfiguračního souboru se berou parametry pro PGP, implicitní instalační prefix pro relokovatelné balíky a podobně.

--root <cesta>

- instaluje tak, že adresář <cesta> je považován za kořenový. Pod adresářem <cesta> se očekává kompletní systém včetně RPM databáze a dalších programů. RPM se do tohoto adresáře přepne a nastaví jej jako kořenový pomocí chroot(2).

--dbpath <cesta>

- jiná než implicitní cesta k RPM databázi (implicitně je /var/lib/rpm).

To je o instalaci RPM balíků zatím všechno. Příští část našeho seriálu bude o upgradování a rušení balíků.


Rušení balíků v systému RPM

Čas od času se ukáže, že v systému určitý software už nepotřebujete, a že byste ho chtěli smazat, odinstalovat. V systému RPM je mazání balíku jednoduché - stačí k tomu příkaz rpm -e <balík>:

# rpm -e xbill
#

Jak vlastně rušení balíků probíhá? RPM nejprve zkontroluje, jestli se případným smazáním balíku neporuší závislosti (například smazáním knihovny libc by přestaly fungovat všechny programy, které jsou proti ní dynamicky linkovány). Je-li vše v pořádku, spustí se pre-uninstall skript tak, jak je uveden v příslušném balíku. Dále systém projde všechny soubory patřící k balíku a smaže je (pokud nejsou ovšem zároveň součástí jiného balíku). S konfiguračními soubory je zacházeno zvlášť opatrně: byl-li konfigurační soubor od instalace balíku změněn, RPM jej nesmaže, ale přejmenuje tak, že souboru přidá koncovku .rpmsave.

Co dále rpm -e umí?

Samozřejmě jako u většiny ostatních variant můžeme získat podrobnější výstup použitím přepínače -v, resp. -vv. Dále je možné přepínačem --nodeps vypnout kontrolu závislostí mezi balíky (pak se ale nesmíme divit, když něco nebude fungovat). Přepínač --test provede test odinstalování balíku - zkontroluje dependence a zjistí, které soubory by smazal (přepínačem -vv lze tyto informace i zobrazit.

Upgradování RPM balíků

Upgradování je proces podobný instalaci balíku. Rozdíl je v tom, že se zároveň smažou případné starší verze téhož balíku. V podstatě tedy není důvod k instalování balíku pomocí rpm -i - použijeme-li místo toho upgrade, provede se správná činnost i v případě, že jde vlastně o instalaci.

Vlastní instalaci balíků pomocí rpm -i použijeme víceméně jen tehdy, když chceme balík nainstalovat bez toho, abychom zároveň smazali případné další nainstalované verze téhož balíku. Pokud například chceme takto mít v systému dvě verze libc, můžeme obě nainstalovat pomocí rpm -i. V případě, že takto instalované balíky neobsahují společné soubory, je instalace bezkonfliktní a naprosto v pořádku. V naprosté většině případů ale pro instalaci balíku stačí upgradovací příkaz, rpm -U.

Proč vlastně upgradovat?

Mohlo by se zdát, že upgrade je v podstatě odinstalování starého a nainstalování nového balíku. A že tedy jedinou výhodou rpm -U oproti rpm -e; rpm -i je to, že ušetříme jeden příkaz. Není tomu tak. Oproti předchozím dvěma příkazům se rpm -U chová trochu jinak. První rozdíl je v zacházení s konfiguračními soubory a druhý rozdíl je v tom, že pre/post-install a pre/post-uninstall skripty umí poznat, kdy jde o upgrade balíku a kdy jde o jeho první instalaci, resp. smazání poslední instance balíku. Každý takový skript dostává jako svůj první parametr číslo, které udává počet existujících instancí daného balíku v systému. Takto může například post-uninstall skript programu squid zjistit, že probíhá definitivní zrušení tohoto balíku a smazat z /etc/passwd uživatele squid. Naopak post-instalační script může vědět, že při upgradu na rozdíl od instalace se nemá snažit inicializovat databázi squidu v adresáři /var/cache.

Podrobnější popis si zaslouží zacházení rpm -U s konfiguračními soubory. Jak víme, RPM si uchovává o každém souboru (nejen konfiguračním) jeho MD5 kontrolní součet. Nyní se v systému mohou vyskytnout ke každému konfiguračnímu souboru tři MD5 součty: první patří původnímu balíku tak, jak je v RPM databázi, druhý patří souboru, který je právě na disku a třetí patří konfiguračnímu souboru v nově instalovaném RPM balíku. Pravidla pro zacházení s konfiguračními soubory jsou tato:

  • Je-li MD5 součet souboru na disku totožný se součtem původního nebo nově instalovaného souboru, RPM smaže konfigurační soubor a nahradí jej novým (ano, i v případě, že soubor na disku má stejný MD5 součet jako v novém balíku - toto je kvůli případným změněným přístupovým právům případně kvůli pevným linkům na konfigurační soubor).
  • Je-li MD5 součet konfiguračního souboru ve starém a novém balíku stejný, ale na disku má soubor jiný MD5 součet, je na disku ponechán konfigurační soubor tak, jak je. Logika tohoto přístupu je zřejmá: Od poslední verze se pravděpodobně neměnila syntaxe konfiguračního souboru, takže je možno zachovat lokální změny.
  • Pokud se MD5 součty všech tří zmiňovaných instancí daného souboru navzájem liší, nainstaluje rpm -U konfigurační soubor z nového balíku a původní konfigurační soubor uloží do souboru s příponou .rpmsave. Dále RPM vypíše varovné hlášení:
    warning: /etc/squid/squid.conf saved as 
    /etc/squid/squid.conf.rpmsave
    

    Vysvětlení je opět jednoduché: V novém balíku je jiný konfigurační soubor než ve starém. Je tedy pravděpodobné, že se změnila syntaxe konfiguračního souboru, a že tedy nový konfigurační soubor by měl být nainstalován. Na druhou stranu uživatel původní soubor změnil a jeho změny by neměly být ztraceny. Proto se tedy uloží původní konfigurační soubor pod jiným jménem. Pokud provádíme upgrade celého systému RedHat, je možné si podobná varovná hlášení přečíst po skončení upgradu v souboru /tmp/upgrade.log.

    V novějších verzích RPM může autor balíku specifikovat, že nechce přepsat původní verze konfiguračních souborů. RPM pak nechává původní konfigurační soubor beze změny a nový uloží s příponou .rpmnew.

  • Poslední nezřejmou možností je, že se ve starší verzi balíku daný konfigurační soubor vůbec nevyskytuje, ale na disku se nachází a má jiný MD5 součet než tento soubor v novém balíku. V tomto případě by RPM také nemělo ztratit potenciálně důležitý obsah konfiguračního souboru. Na druhé straně by mělo být vidět, že jde o konfigurační soubor "podezřelého" původu, bez předchozího výskytu v RPM databázi. Původní konfigurační soubor se tedy přejmenuje na soubor s koncovkou .rpmorig.

Co se týče přepínačů, které rpm -U akceptuje, jsou v podstatě stejné, jako u instalace (rpm -i). Navíc je zde přepínač --oldpackage, který slouží k downgradování balíků (instalaci starší verze než je stávající). Tento přepínač jistě využijete, pokud budete zkoušet používat některé alfa a beta verze softwaru a pak se budete chtít vrátit ke stabilní starší verzi. Do přepínače --force je oproti instalaci balíku zahrnuta i funkce volby --oldpackage.

To je k upgradování RPM balíků vše. V příští části tohoto seriálu bude řeč o získávání informací z databáze RPM.


Získávání informací z databáze RPM

V předchozích dílech našeho seriálu jsme viděli, že systém RPM udržuje množství informací o nainstalovaných balících i o jednotlivých souborech v nich. Tyto informace pak používá při další práci s RPM balíky - při jejich instalaci, rušení a povyšování. Systém RPM ale také umí tyto informace zpřístupnit uživateli pomocí několika druhů dotazů. A o dotazech na databázi RPM bude řeč v tomto dílu.

K čemu lze tyto dotazy použít?

Dotazování se provádí příkazem rpm -q. Uvedu zde několik příkladů situací, které řeší dotaz do RPM databáze:

  • Na vašem stroji je soubor /usr/include/pthread.h, ale nevíte, ze kterého balíku tento soubor pochází.
  • Nedávno jste si nainstaloval Secure Shell a chcete k němu najít nějakou dokumentaci.
  • Získáte software, o němž autor tvrdí, že potřebuje libc verze aspoň 5.4.30. Chcete zjistit, jaká je vlastně verze libc na vašem systému.
  • Narazili jste na síti na RPM balík a chcete zjistit, co obsahuje.
  • Právě jste upgradovali systém na libc verze 6 a chcete zjistit, které balíky na vašem systému stále ještě potřebují starší verzi libc 5.

Toto je ovšem jen několik příkladů. Nyní podrobně k jednotlivým částem dotazu. Dotaz se skládá ze dvou hlavních částí - první určuje množinu balíků, o nichž chcete informace zjistit, druhá říká, jaké informace se o těchto balících chcete dovědět.

Část první - výběr balíků

  • Dotaz můžete omezit na balík určitého jména. Takto například zjistíte aktuální verzi nainstalovaného balíku:
    $ rpm -q squid
    squid-1.NOVM.20-3
    
    
    $ rpm -q postgresql
    package postgresql is not installed
    

    Je vidět, že pokud specifikujeme jen část dotazu pro výběr balíků, ale nikoli část specifikující požadované informace, dostane se nám odpovědi ve formě jména balíku, jeho verze a jeho release (oddělěno pomlčkami) a nového řádku.

  • Na druhé straně můžeme vypsat všechny balíky v systému. K tomu slouží přepínač -a:
    $ rpm -qa|sort  
    ElectricFence-2.0.5-5
    MAKEDEV-2.3.1-1
    ...
    zlib-devel-1.0.4-2
    
  • Dále lze dotaz omezit na balíky, kterým patří nějaký soubor v systému pomocí přepínače -f soubor:
    $ rpm -qf /etc/printcap 
    setup-1.9-2
    

    Zde je nutno dát pozor na to, že RPM si v databázi ukládá balíky s absolutní cestou, a že tedy dotazy mohou být zodpovězeny rozdílně, přestože se jedná o tentýž soubor:

    $ rpm -qf /etc/X11/xdm/Xaccess XFree86-3.3.1-14 $ rpm -qf /usr/lib/X11/xdm/Xaccess file /usr/lib/X11/xdm/Xaccess is not owned by any package

  • Lze se také dotazovat na RPM soubor, který nemusí být zatím nainstalovaný. Jak víme, v RPM souboru je přímo uložen jeho název, takže jej lze zjistit i po přejmenování:
    $ rpm -qp trubka 
    passwd-0.50-10
    
  • Jak již bylo řečeno na začátku tohoto seriálu, jsou RPM balíky sdružovány do tematických skupin. Chceme-li si vypsat všechny aplikace, které se týkají práce se zvukem, použijeme následující příkaz:
    $ rpm -qg Applications/Sound 
    cdp-0.33-8
    maplay-1.2-6
    sox-11g-6
    timidity-0.2i-2
    
  • Někdy potřebujeme zjistit, který balík poskytuje určitou vlastnost, kterou mohou jiné balíky vyžadovat - například chceme zjistit, který balík poskytuje libc verze 6:
    $ rpm -q --whatprovides libc.so.6 
    glibc-2.0.6-9
    
  • Duálním problémem k předchozímu je zjištění seznamu balíků, které vyžadují danou vlastnost - například v úvodu zmiňovaný dotaz na balíky, které ještě vyžadují starší verzi libc:
    $ rpm -q --whatrequires libc.so.5 
    xpdf-0.7-2
    snd-1-1
    timidity-0.2i-2
    

Část druhá - výběr informací

V předchozí části jsme viděli, že implicitně se vypisuje jméno balíku, jeho verze a release. Můžeme ale zjišťovat také množství jiných informací. Nejprve si ukážeme některé přepínače pro podrobnější výpis, a v závěru popíšeme konstrukci jakkoli obecného výpisu informací.

  • Přepínačem -i získáme výpis souhrnných informací o daném balíku. Předpokládejme například, že nám někdo dal nějaký RPM soubor, a my o něm chceme zjistit podrobnosti (viz výpis Informace o RPM balíku).
$ rpm -qpi soubor.rpm Name : squid Distribution: (none) Version : 1.NOVM.20 Vendor: (none) Release : 3 Build Date: Sun Feb 1 00:50:11 1998 Install date: Sun Feb 1 09:19:37 1998 Build Host: gloin Group : Networking/Daemons Source RPM: squid-1.NOVM.20-3.src.rpm Size : 693576 Packager : Jan "Yenya" Kasprzak <kas@fi.muni.cz> URL : http://squid.nlanr.net/ Summary : Squid Internet Object Cache Description : Squid is a caching proxy for www/ftp/gopher Please read the documentation-Files!!

Výpis 15: Informace o RPM balíku

  • Výpis obsahuje množství informací. Lze z něj například zjistit, že někteří lidé dokáží v neděli v jednu hodinu v noci vyrábět RPM balíky :-). Myslím, že výše uvedený výpis nepotřebuje podrobnější komentář k jednotlivým položkám.
  • Přepínač -l - seznam souborů v balíku:
    $ rpm -ql ncftp 
    /etc/X11/wmconfig/ncftp
    /usr/bin/ncftp
    /usr/man/man1/ncftp.1
    
  • V předchozí části tohoto seriálu jsme viděli, že RPM může dělat rozdíly mezi jednotlivými soubory v balíku. Rozeznává soubory běžné, konfigurační a dokumentaci. Příslušný typ souboru můžeme zjišťovat - seznam konfiguračních souborů přes přepínač -c a seznam dokumentace pomocí -d. Například seznam dokumentace k programu /bin/bash můžeme získat takto:
    $ rpm -qdf /bin/bash 
    /usr/doc/bash-1.14.7
    /usr/doc/bash-1.14.7/NEWS
    /usr/doc/bash-1.14.7/README
    /usr/doc/bash-1.14.7/RELEASE
    /usr/info/bash.info.gz
    /usr/man/man1/bash.1
    /usr/man/man1/sh.1
    

    Jak přepínač -l, tak přepínače -c a -d mohou o souborech vypsat detailní informace pomocí klíče -v.

  • Získání stavu jednotlivých souborů. Každý soubor daného balíku může být v jednom ze čtyř stavů:
    • normal: soubor je nainstalován v systému.
    • replaced: soubor byl přepsán souborem z jiného RPM balíku použitím --replacefiles (resp. --force).
    • not installed: balík byl nainstalován, ale tento soubor ne (například při použití parametru --excludedocs).
    • net shared: soubor se nachází na svazku, který byl v /etc/rpmrc označen jako síťový. Takovýto soubor není spravován RPM databází (resp. je spravován RPM databází na síťovém serveru).
    Příslušný stav ke každému souboru lze zjistit pomocí přepínače -s.
  • Informace o tom, jaké vlastnosti daný balík poskytuje do systému. Balík například může obsahovat sdílené knihovny a podobně:
    $ rpm -q --provides db  
    libdb.so.2
    
  • Naopak můžeme zjistit informaci o tom, které vlastnosti (včetně verzí) daný balík vyžaduje ke správnému běhu:
    $ rpm -q --requires glint 
    /usr/bin/python  
    /bin/sh  
    tkinter  
    pythonlib >= 1.12
    python >= 1.4
    
  • Lze vypsat i pre/post-install a pre/post-uninstall skripty, které k balíku patří. Dosáhneme toho volbou --scripts.

Konstrukce obecných dotazů

Výše uvedené příklady popisovaly určité speciální typy dotazů. RPM ale umožňuje vypisovat odpovědi v úplně obecné formě. Nebudeme zde podávat vyčerpávající výpis, jen v krátkosti a na několika příkladech vysvětlíme logiku tohoto systému.

Základem obecného dotazu je volba --queryformat řetězec. Tento řetězec je vypsán pro každý dotazovaný balík s tím, že některé zvláštní konstrukce se nahradí příslušnými informacemi o RPM balíku. Je to trochu podobné nahrazování řetězců s procenty v knihovní funkci printf(3). RPM podporuje substituci zpětného lomítka podobně jako printf(3), takže je například možné psát následující konstrukce:

$ rpm -qa --queryformat 'Ahoj, babi!\n' 

Tento příkaz vypíše jmenovaný řetězec tolikrát, kolik je v systému nainstalovaných balíků.

Pokračujme v příkladech. Následující příkaz ukazuje implicitní formát výpisu odpovědi a jeho výstup je stejný, jako když část --queryformat neuvedeme:

$ rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\n' squid

Z příkladu je vidět, že RPM nahrazuje konstrukci %{atribut} obsahem daného atributu z databáze. Nebudu zde rozebírat všechny dostupné atributy, jen uvedu, že pomocí následujícího příkazu získáme seznam všech atributů platných v dané verzi RPM:

$ rpm --querytags |sort 
ARCH
ARCHIVESIZE
...
VERSION
XPM

Některé atributy jsou v databázi ukládány ve formě čísla, ale uživatel by mohl chtít toto číslo zobrazit nějak jinak. Například datum se ukládá jako počet sekund od 1. ledna 1970, ale textový výpis je čitelnější. Výpisu v jiném formátu dosáhneme například takto:

$ rpm -q --queryformat '%{INSTALLTIME:date}\n' bash 
Sat Jan 31 17:53:00 1998

Kromě formátovacího řetězce :date pro výpis času existují ještě tyto:

  • :perms - výpis přístupových práv.
  • :deflags - výpis závislostí mezi balíky.
  • :fflags - konverze čísla na c, d nebo mezeru podle toho, jestli jde o konfigurační, dokumentační nebo běžný soubor.

Dále lze jednotlivé položky zarovnávat a vypisovat na určitý počet znaků podobně jako v printf(3):

$ rpm -q --queryformat '%4{RELEASE}\n' squid 
   5

Některé položky v databázi lze vyhodnotit vícekrát pro jeden balík (například %{FILENAMES} - jména souborů v balíku). Můžeme proto chtít například jeden řádek pro každý soubor v balíku. Nebudu se pouštět do syntaktických podrobností, jen uvedu příklad:

$ rpm -q --queryformat '%{NAME} obsahuje \
soubory:\n[%{FILENAMES} (%{FILESIZES} bytes)\n]' bash 
bash obsahuje soubory:
/bin/bash (301580 bytes)
/bin/sh (4 bytes)
...
/usr/man/man1/sh.1 (6 bytes)

To je k dotazům do RPM databáze všechno. Příště se budeme věnovat kontrole integrity balíků a dalším vlastnostem.


Kontrola integrity RPM balíků

V předchozí části tohoto seriálu jsme viděli, jaké informace systém RPM udržuje o jednotlivých balících a jejich souborech. V minulém čísle jsme si dokonce ukazovali, jak tyto údaje ze systému získat. V tomto čísle bude řeč o kontrole integrity balíků - co dělat, chceme-li zjistit, jestli soubory, které se v systému nacházejí, mají vůbec ještě nějaký vztah k RPM balíku, ze kterého byly kdysi nainstalovány.

Soubory a verifikační skripty

K verifikaci RPM balíků slouží přepínač -V, resp. -y nebo též --verify příkazu rpm. Systém RPM umí kontrolovat jednak integritu souborů příslušných RPM balíkům, a jednak správnost konfigurace. První z kontrol se provádí oproti RPM databázi nebo .rpm-balíku samotnému, druhá je prováděna pomocí verifikačního skriptu, který může být součástí RPM balíku. Tam si autor balíku může sám napsat cokoli, co zkontroluje například syntaxi konfiguračních souborů (uživatelé systému UUCP si jistě vzpomenou na program uucheck). Poslední věcí, kterou RPM kontroluje, jsou závislosti mezi balíky.

Kontrola souborů

Následujících devět atributů se může u každého souboru v daném balíku kontrolovat:

  • vlastník souboru
  • skupina souboru
  • přístupová práva
  • kontrolní součet (metoda MD5)
  • velikost souboru
  • hlavní číslo zařízení
  • vedlejší číslo zařízení
  • cíl symbolického linku
  • čas poslední modifikace

Ne všechny atributy jsou pochopitelně smysluplné u všech souborů - například cíl symbolického linku lze zřejmě kontrolovat pouze u souborů typu symbolický link. Taktéž hlavní a vedlejší číslo je platné pouze u speciálních souborů. Naopak MD5 součet je u speciálních souborů k ničemu. Navíc sám autor balíku má možnost zakázat verifikaci určitého atributu pro konkrétní soubor. Například terminálová zařízení mění svého vlastníka (nikoli však skupinu) podle toho, kdo je momentálně na daném terminálu přihlášen. Proto by bylo nemoudré verifikovat vlastníka takového souboru.

Nesouhlasí-li hodnota některého atributu ve skutečnosti a v databázi, RPM o tom vypíše zprávu. Pro každý změněný soubor je ve výstupu jeden řádek. Na řádku je seznam atributů, které nesouhlasí, případně písmeno c, jde-li o konfigurační soubor, a cesta k souboru. Seznam je uveden ve formě osmiznakového řetězce, kde na místě změněných atributů je písmeno, a na místě nezměněných nebo neverifikovaných atributů je tečka. Výstup může vypadat asi takto:

$ rpm -V bash
.M5....T c /etc/bashrc

Na místě teček mohou být tyto atributy (podle pořadí v seznamu):

  • S - velikost
  • M - přístupová práva
  • 5 - MD5-součet
  • D - hlavní a vedlejší číslo zařízení
  • U - vlastník
  • G - skupina
  • T - čas poslední modifikace

Je vidět, že v našem příkladu byl soubor bashrc modifikován. Je změněn jeho obsah (MD5 součet), čas modifikace a přístupová práva. Pokud soubor, který se má verifikovat, vůbec neexistuje, je místo seznamu atributů vypsáno slovo missing. Je-li verifikace balíku úspěšná, RPM nevydává žádný výstup.

Co se má kontrolovat?

Jak jsme již viděli výše, stačí příkazu rpm -V dát jako parametr seznam balíků, které má zkontrolovat. Kromě toho existují tyto další možnosti:

  • -a - kontrola všech balíků, které jsou právě v systému nainstalovány.
  • -f soubor - kontrola balíku, kterému patří daný soubor.
  • -p soubor.rpm - provádí kontrolu balíku nikoli proti RPM databázi, ale proti balíku samotnému. Toto se použije zejména v případě, kdy si nejsme úplně jisti platností RPM databáze nebo když databáze vůbec neexistuje.
  • -g skupina - kontrola všech nainstalovaných balíků, patřících do dané skupiny (například rpm -Vg Shells zkontroluje všechny shelly).

Další možnosti

Kromě výše uvedených přepínačů lze také specifikovat, které části verifikačního procesu se mají provést. Jednotlivé části lze vypnout těmito volbami:

  • --nodeps - neprovádí kontrolu závislostí mezi balíky.
  • --noscripts - nespouští verifikační skript.
  • --nofiles - neprovádí kontrolu

Za zmínku stojí ještě přepínače -v, resp. -vv, které zvyšují podrobnost vypisovaných informací (například zapínají výpis standardního vstupu verifikačního skriptu, resp. i jednotlivé příkazy, tímto skriptem prováděné).

Tento díl našeho seriálu o systému RPM uzavírá první část zaměřenou na běžné uživatele. Od příště se budeme věnovat vlastní tvorbě RPM balíků.


Tvorba RPM balíků

V předchozích dílech našeho seriálu o systému RPM jsme rozebírali všechny vlastnosti RPM z hlediska uživatele. V další části se budeme věnovat RPM z hlediska vlastní tvorby RPM balíků. Co tedy dělat, máme-li nějaký software a chceme jej zabalit do RPM balíku?

Kompilace

První činnost, kterou je nutno před vlastním zabalením softwaru do formátu RPM udělat, je zkompilovat software pod Linuxem a ujistit se, jestli vůbec pod Linuxem funguje. V následujícím budeme předpokládat, že software lze bez problémů zkompilovat a že také funguje. Jako příklad si vezmeme program gmemusage, který slouží k měření obsazení operační paměti jednotlivými procesy. K jeho zkompilování a nainstalování stačí spustit příkazy make a make install.

Rychlý start

Bez jakéhokoli vysvětlování uvedu příklad, jak vyrobit RPM-balík gmemusage (vysvětlení bude následovat):

  • Jako root nakopírujte soubor http://reality.sgi.com/raju/software/gmemusage-0.2.tar.gz do adresáře /usr/src/redhat/SOURCES/.
  • Nakopírujte soubor na výpise Soubor SPEC pro gmemusage pod názvem gmemusage-0.2.spec do adresáře /usr/src/redhat/SPECS/.
  • V adresáři /usr/src/redhat/SPECS spusťte příkaz rpm -ba gmemusage-0.2.spec. Výsledkem by měl být zdrojový RPM soubor gmemusage-0.2-1.src.rpm v adresáři /usr/src/redhat/SRPMS (k čemu jsou zdrojové RPM soubory, uvidíme později) a binární RPM pro danou architekturu (gmemusage jsem zkoušel vyrábět pouze pro platformu i386 a sparc, ale pro sparc měl program jisté problémy. Binární RPM soubor je v RPMS/i386/gmemusage-0.2-1.i386.rpm.
  • Nově vytvořený RPM soubor lze nainstalovat příkazem rpm -Uvh RPMS/i386/gmemusage-0.2-1.i386.rpm.
Summary: graphics memory usage meter Name: gmemusage Version: 0.2 Release: 1 Source: http://reality.sgi.com/raju/software/gmemusage-0.2.tar.gz Copyright: GPL Group: Utilities/System Packager: Jan "Yenya" Kasprzak <kas@fi.muni.cz> BuildRoot: /tmp/gmemusage-root %description This tool displays the bar graph describing memory usage of processes on the Linux box. Uses /proc filesystem. %prep %setup %build make OPTIM="$RPM_OPT_FLAGS" %install mkdir -p $RPM_BUILD_ROOT/usr/X11R6/{bin,man/man1} make PREFIX=$RPM_BUILD_ROOT/usr/X11R6 install %files %attr(0775,root,root) /usr/X11R6/bin/gmemusage %attr(0644,root,root) /usr/X11R6/man/man1/gmemusage.1

Výpis č. 6: Soubor SPEC pro gmemusage

Vysvětlení

A teď zpět k tomu, co jsme vlastně v předchozí sekci udělali. Je vidět několik základních faktů:

  • RPM využívá adresář /usr/src/redhat.
  • používá se příkaz rpm -ba
  • tvorba balíku je řízena souborem s koncovkou .spec.
  • vytváří se zároveň zdrojový i binární RPM soubor.

Adresář /usr/src/redhat obsahuje tyto podadresáře (lze změnit v souboru /etc/rpmrc, což umožní vyrábět RPM balíky i jako běžný uživatel):

  • SPECS - obsahuje spec-soubory, které řídí vlastní sestavování RPM balíku.
  • SOURCES - zde jsou zdrojové soubory, ze kterých se balík vytváří.
  • BUILD - do tohoto adresáře se rozbalí zdrojové soubory a probíhá zde kompilace.
  • RPMS/architektura - sem se uloží výsledné RPM soubory.
  • SRPMS - zde budou výsledné zdrojové RPM soubory.

SPEC soubor

Tento soubor řídí celou kompilaci. Jeho příklad byl uveden, jednotlivé možnosti budou podrobně popsány v následujících dílech tohoto seriálu.

Na začátku souboru je hlavička, která popisuje, o jaký balík se jedná, odkud pochází zdrojový text, kdo balík vytvořil, jaká je jeho licence, a množství dalších informací, později z balíku vypsatelných pomocí rpm -q.

Dále následují jednotlivé sekce - jsou odděleny klíčovým slovem s procentem na začátku řádku. V našem příkladu jsou použity tyto sekce:

  • %description - popis balíku, který dále rozvíjí krátkou informaci ze Summary: v hlavičče souboru.
  • %prep - příprava na kompilaci. Tato sekce se vykoná jako shellovský skript a má za úkol provést rozbalení zdrojového archívu, aplikaci případných záplat, konfiguraci a podobně. Ve výše uvedeném souboru tato sekce obsahuje jediný příkaz - makro (pozor, ne sekci) %setup, které dělá přesně to, že do adresáře BUILD rozbalí archív, uvedený v hlavičče jako Source: z adresáře SOURCES. Tedy z celého tam uvedeného URL se použije pouze část za posledním lomítkem. Ostatní slouží jen pro informaci.
  • %build - vlastní kompilace. Jde opět o shellovský skript. Zde je dobré si všimnout proměnné $RPM_OPT_FLAGS - jednotlivé skripty dostávají od RPM přednastavené některé proměnné. Tato proměnná je jednou z nich a obsahuje implicitní volby předávané kompilátoru pro optimalizaci. Takže změnou tohoto parametru například v /etc/rpmrc můžeme dosáhnout toho, aby se všechny nově kompilované balíky stavěly s těmito volbami.
  • %install - vlastní instalace souborů v balíku. V běžných případech se v tomto skriptu spouští příkaz make install. Je ovšem dobré, pokud rekompilace RPM balíku neprovede instalaci do skutečného systému, ale někam do vlastního stromu. Tato vlastnost se jmenuje Buildroot a zapíná se uvedením stejnojmenného parametru v hlavičce spec-souboru. RPM pak vytvoří jmenovaný adresář a nastaví skriptům (včetně toho %install) proměnnou $RPM_BUILD_ROOT. Výhoda tohoto přístupu je v tom, že takto může bez modifikace spec-souboru vytvořit RPM balík i běžný uživatel, nikoliv jen superuživatel.
  • %files - popisuje, které soubory mají být zahrnuty do RPM balíku. Tato sekce není shellovský skript, ale seznam. Je možno též specifikovat atributy jednotlivých souborů, čímž umožníme vytvořit RPM balík i běžnému uživateli. Neuvedeme-li atributy, RPM vezme takové atributy, jaké má jmenovaný soubor v době tvorby balíku.

Příkaz rpm -b

K vytváření RPM balíků se používá příkaz rpm -b. Jeho argumentem je .spec soubor. Akceptuje následující přepínače:

  • -p Vykoná pouze %prep sekci ve spec-souboru.
  • -l Zkontroluje, jestli soubory jmenované v sekci %files skutečně existují.
  • -c Vykoná %prep a %build.
  • -i Vykoná %prep, %build a %install.
  • -b Vytvoří binární RPM soubor (po vykonání %prep, %build a %install).
  • -a Vytvoří binární a zdrojový RPM soubor (po vykonání %prep, %build a %install).
  • --short-circuit Používá se ve spojitosti s -bc a -bi. Vykoná pouze jmenovanou sekci, bez předchozích.
  • --timecheck číslo Vypíše varování, pokud se snažíme do RPM balíku zabalit soubor starší než daný počet sekund.
  • --clean Smaže kompilační strom příslušného balíku v adresáři /usr/src/redhat/BUILD po skončení tvorby balíku.
  • --test Otestuje syntaxi spec-souboru, neprovádí žádné kompilační akce.
  • --sign Vytvoří balík s PGP podpisem.

Kromě rpm -b lze také použít rpm -t a jako parametr uvést soubor ve formátu tar.gz. Takovýto archív se rozbalí a jako spec-soubor se použije první soubor s koncovkou .spec, obsažený v archívu. Při kompilaci se samozřejmě neprovádí sekce %prep.

Zdrojové RPM soubory

Již několikrát padla zmínka o zdrojových RPM souborech. To je soubor s koncovkou .src.rpm. Takovýto soubor obsahuje v sobě spec-soubor příslušného balíku, dále všechny soubory potřebné k sestavení binárního RPM balíku (zejména soubory uvedené v hlavičce v položce Source) a případnou ikonku RPM balíku.

Zdrojový RPM balík lze zpracovávat třemi způsoby. První možnost je tento balík nainstalovat pomocí rpm -i. Všechny soubory, které zdrojový balík obsahuje, jsou nainstalovány do adresáře SOURCES a spec-soubor je poté přesunut do adresáře SPECS. Další dvě možnosti jsou vytvoření binárního RPM balíku pro danou architekturu, případně vytvoření jak binárního, tak i zdrojového RPM balíku. Dosáhneme toho příkazem rpm --recompile balík.src.rpm, případně rpm --rebuild balík.src.rpm. Oproti příkazu rpm -ba se navíc implicitně smaže kompilační adresář tak, jako kdybychom použili --clean.

To zatím jako úvod do problematiky tvorby vlastních RPM balíků stačí. Příště se podrobněji vrátíme k formátu spec-souboru a k podrobnostem této problematiky.


Vytváření RPM balíků

V dnešním díle našeho seriálu budu pokračovat ve výkladu problematiky tvorby RPM balíků. Nejprve doplním o některé podrobnosti syntaxi příkazu rpm -b, a pak začnu detailněji rozebírat strukturu spec-souboru.

rpm -ba - detaily

V předchozím čísle jsem uvedl základní způsoby použití příkazu rpm -b pro stavbu RPM balíků. Nyní uvádím další, méně užívané volby:

  • --buildarch architektura - vytvoří RPM balík pro danou architekturu místo architektury, na které právě systém běží. Lze použít zejména při cross-kompilaci.
  • --buildos operační systém - totéž, ale změní operační systém, pro který bude balík určen.
  • --test - vytvoří skripty pro jednotlivé fáze kompilace (uloží je do adresáře /var/tmp) a skončí. Tvůrce balíku pak má možnost si tyto skripty prohlédnout a případně i editovat.
  • --buildroot adresář - pro instalaci balíku se použije tento adresář, místo adresáře uvedeného v hlavičce BuildRoot: ve spec-souboru.

Uvnitř spec-souboru

Zaměřme se nyní na syntaxi spec-souboru, který řídí celou výstavbu RPM balíku. Jedna z věcí, kterou spec-soubor může obsahovat, je komentář. Komentáře zde začínají znakem křížek (#) na začátku řádku a pokračují do konce řádku. Komentáře jsou programem rpm ignorovány.

Další částí je hlavička. Syntaxe se trochu podobá hlavičce internetové zprávy podle RFC 822: Hlavička je umístěna na začátku spec-souboru a obsahuje položky ve formě řádků. Každý řádek definuje hodnotu jednoho tagu (česky atributu? Asi ne.) a má tuto syntaxi:

tag:hodnota

U jména tagu se nerozlišují malá a velká písmena a kolem dvojtečky mohou být bílé znaky (mezery, tabulátory, ...). Na druhé straně syntaxe hodnoty tagu závisí na konkrétním tagu a obvykle se rozlišuje velikost písmen. Některé tagy mohou mít jen číselné hodnoty, některé nesmějí obsahovat určité znaky (třeba pomlčku), atd. Nyní uvedu, které tagy systém RPM rozpoznává, a jak je použít.

Tagy pro pojmenování balíků

  • name - název softwaru, který se balí do balíku. Doporučuje se, aby tento tag byl stejný (včetně velikosti písmen), jako u zdrojového archívu příslušného softwaru. Příklady: gcc, ImageMagick.
  • version - verze softwaru (to jest verze specifikovaná autorem softwaru). Příklady: 2.7.2.1, 19980302beta.
  • release - verze RPM balíku daného softwaru. Často lze pomocí release rozlišit verze RPM balíku pro různé distribuce nebo různá prostředí. Takže pro secure shell s RSAREF knihovnou může být release 2us, čili pro použití ve Spojených státech. Mezinárodní verze balíku pak může mít tento tag nastavený na hodnotu 2i.

Popisné tagy

  • summary - jednořádková informace o balíku a jeho použití. Již dříve jsem uvedl, že podrobnější informaci lze nalézt v sekci %description příslušného spec-souboru. Příklad: Secure Shell - encrypts network communications.
  • copyright - krátká informace o podmínkách šíření balíku. Nejde o kompletní licenci, ale o její shrnutí nebo název. Příklady: GPL, BSD, distributable, postcardware.
  • distribution - název distribuce, do které balík patří. Příklady: Red Hat Linux Rembrandt, Red Hat Power Tools 5.0.
  • icon - jméno souboru, ve kterém je uložena ikona balíku. RPM systém tento tag nepoužívá, ale může být použit například grafickým správcem balíků, jako je například glint. Jde o grafický soubor například ve formátu xpm nebo gif.
  • vendor - název organizace, která je zodpovědná za vznik tohoto balíku. Příklad: Red Hat Software, Inc..
  • url - domovská stránka balíku. RPM tento tag nepoužívá, slouží pouze uživatelům balíku jako odkaz na další dokumentaci případně novější verze softwaru.
  • group - tematická skupina, do které tento balík patří. Seznam všech platných skupin i jejich podskupin lze nalézt v souboru groups v dokumentačním adresáři RPM (obvykle /usr/doc/rpm-verze). Příklady: Libraries, X11/Games/Strategy.
  • packager - jméno a kontaktní informace (e-mailová adresa, telefonní číslo) člověka, který konkrétní balík vyrobil (případně adresa technické podpory, jde-li o větší firmu).

Závislosti mezi balíky

  • serial - sériové číslo softwaru. Pro potřeby instalace nových verzí balíku (upgradování), ale i pro závislosti mezi balíky (kdy balík může vyžadovat například "balík pam verze novější než x.y.z"), je potřeba určit, která verze softwaru je novější než jiná. V některých případech je však "oficiální" číslování daného softwaru natolik kryptické, že není možné algoritmicky určit, které označení znamená novější verzi. Proto je možné RPM balíku přiřadit sériové číslo a toto číslo používat při (časovém) porovnávání verzí namísto skutečného označení verze. Poznamenávám ještě, že balíky, obsahující tag serial se považují vždy za novější než balíky bez tohoto tagu.
  • provides - jméno jednoho nebo více "virtuálních balíků", které příslušný balík poskytuje. Některé balíky totiž nepotřebují ke své činnosti jiný konkrétní balík, ale určitý typ balíku. Například programy pro doručování pošty mohou vyžadovat existenci programu pro čtení pošty. A je lhostejné, jde-li o exmh, mutt nebo třeba gnus. Takový program pro doručování pošty pak vyžaduje virtuální balík s názvem (například) mail-reader. A každý program pro čtení pošty bude mít ve svém spec-souboru uveden tag Provides: mail-reader.
  • requires - seznam balíků, které náš balík vyžaduje ke korektní činnosti. Některé závislosti jsou generovány automaticky (zejména závislosti na sdílených knihovnách a na interpreterech skriptů), jiné lze specifikovat tímto tagem. Příklad: requires: pam >= 0.51 říká, že ke správnému provozu daného balíku musí být v systému balík pam verze aspoň 0.51. Je také možno vyžadovat verzi balíku podle sériového čísla: requires: playmidi =S 4 vyžaduje jmenovaný balík sériového čísla právě 4. Může zde kromě jména balíku být uveden i jen soubor, který je v systému vyžadován pro korektní činnost balíku. Tento způsob závislostí se specifikuje řetězcem, který začíná lomítkem. Například poštovní klient, odesílající poštu na standardní vstup programu sendmail v podstatě nepotřebuje balík sendmail, ale stačí jakýkoli balík, který poskytne program /usr/sbin/sendmail. Do spec-souboru se pak napíše requires: /usr/sbin/sendmail.
  • conflicts - seznam balíků, které jsou konfliktní (to jest nemohou být v systému instalovány zároveň) s tímto balíkem. Tento tag není příliš často používán, protože většina konfliktů je detekována systémem RPM už z toho důvodu, že navzájem konfliktní balíky obsahují soubory stejného jména a tedy není možné je přímo a zároveň nainstalovat. Příklad conflicts: inn může být uvedeno ve spec-souboru news serveru LeafNode, nechce-li tento být instalován zároveň se serverem inn.
  • autoreqprov - zapíná/vypíná automatické generování položek do seznamu requires (sdílené knihovny ze spustitelných programů a interpretery skriptů) a do seznamu provides (.so-jména všech sdílených knihoven, zabalených v tomto balíku). Povolené hodnoty jsou yes a no.

Tagy architektury a operačního systému

  • excludearch - upozorní RPM, aby se nepokoušel kompilovat balík na vyjmenovaných architekturách, protože je známo, že na těchto platformách daný balík nefunguje. Příklad: není-li balík schopen běžet na 64-bitových architekturách, můžeme napsat excludearch: alpha sparc64.
  • exclusivearch - říká, že balík může být postaven pouze na vyjmenovaných platformách. Například balík dosemu může běžet jen na procesorech x86, tedy exclusivearch: i386 je na místě.
  • buildarchitecture - specifikuje architekturu, pro kterou se balík má vytvářet, bez ohledu na to, na které platformě momentálně běží program rpm, který jej vytváří. Tento tag se používá zejména pro tvorbu balíků, nezávislých na architektuře. Například balík s fonty, které jsou pricipiálně přenositelné mezi platformami, může obsahovat tag buildarchitecture: noarch. Při použití rpm -ba na takovýto spec-soubor na libovolné platformě se vytvoří balík s koncovkou noarch.rpm.
  • excludeos - totéž jako excludearch, ale týká se operačního systému místo architektury. Příklad: balík WINE by klidně mohl mít excludeos: windows95 :-)
  • exclusiveos - analogie k exclusivearch. Příklad: balík util-linux jistě může mít exclusiveos: linux.
  • buildos - analogie k buildarchitecture.

Adresáře

  • prefix - používá se při tvorbě relokovatelných balíků (tj. nezávislých na umístění). Je-li tento tag uveden, musí každá cesta v sekci %files začínat daným adresářem. Relokovatelný balík pak správce může instalovat do adresáře podle své potřeby (například zvolit mezi /usr/local a /opt). Vytvořit relokovatelný balík ovšem není tak úplně jednoduché - samotný software musí být nezávislý na umístění. Nesmí tedy například obsahovat zakompilovanou cestu ke konfiguračním souborům, PID-souborům a podobně.
  • buildroot - s tímto tagem jsme se setkali. Navzdory svému jménu neoznačuje adresář, ve kterém probíhá kompilace, ale adresář, do kterého skript %install uloží zkompilované soubory. Je dobré mít tento tag v balíku, aby i běžný uživatel mohl provádět jeho rekompilaci. Typicky se zde uvádí jméno ve stylu /var/tmp/balík-root. Bez tohoto tagu by běžnému uživateli selhala sekce %install, jelikož běžný uživatel pravděpodobně nemůže zapisovat do adresářů jako /usr/bin nebo /usr/doc. Zároveň s definicí tohoto tagu je ovšem nutno upravit skript %install tak, aby instaloval do zde specifikovaného adresáře. Zde již tedy nestačí prosté make install. Často ale změna není až tak složitá. Někdy postačuje příkaz typu make PREFIX=$RPM_BUILD_ROOT/usr install.

Zdrojové soubory a záplaty

  • source - jméno nebo URL, odkazující na zdrojový archív, ze kterého se daný balík vytváří. Tagů source lze uvést i více (další se pak jmenují source1, source2 atd. Místo source lze také použít logický ekvivalent source0. Program rpm z hodnoty tohoto tagu bere v úvahu pouze část za posledním lomítkem. Soubor tohoto jména se hledá v adresáři /usr/src/redhat/SOURCES. URL nebo cesta slouží pouze jako odkaz na místo, odkud byl zdrojový archív získán. Příklad: balík ssh má tyto zdrojové soubory: Source0: ftp://ftp.cs.hut.fi/pub/ssh/\ ssh-1.2.25.tar.gz Source1: ftp://ftp.funet.fi/pub/crypt/mirrors/... Source2: sshd.init.rh50 Source3: ssh.pam Source4: ftp://ftp.cs.hut.fi/pub/ssh/\ ssh-1.2.25.tar.gz.sig Zde vyjmenované soubory mohou, ale nemusejí být použity ke tvorbě binárního RPM balíku, každopádně ale jsou zařazeny do zdrojového RPM balíku (to je třeba případ výše uvedeného source4, který obsahuje PGP podpis zdrojového archívu a je distribuován pouze pro usnadnění ověření pravosti tohoto archívu.
  • patch - odkazuje záplatu, používanou při sestavování daného softwaru. Podobně jako u tagu source i záplat může být více a jsou označeny tagy patch0 (což je ekvivalent tagu patch), patch1, patch2 a tak dále.
  • nosource - seznam čísel zdrojových souborů, které nemají být zařazeny do src.rpm balíku. Pokud licence daného softwaru nepovoluje šíření zdrojové podoby balíku v jiné než původní podobě, nebo pokud z jiného důvodu nechceme některý ze zdrojových archívů zahrnout do zdrojového RPM souboru, napíšeme jeho číslo do tagu nosource. Pokud si pak uživatel chce postavit binární RPM soubor, stačí příslušný zdrojový archív uložit do /usr/src/redhat/SOURCES a spustit rpm --rebuild na příslušný src.rpm soubor. Příklad: pokud by například RPM balík pgp byl distribuován z USA, podle tamějších zákonů by se vlastně mohl distribuovat jen předpis ke kompilaci - zdrojový RPM soubor. Použily by se tyto tagy:
    Source0: ftp://.../pgp50.tar.gz
    Source1: ftp://.../rsaref.tar.gz
    NoSource: 0 1
    
  • nopatch - analogie k nosource pro soubory se záplatami.

Takto tedy vypadají jednotlivé položky hlavičky spec-souboru. V příští části se podrobněji zaměříme na další sekce tohoto souboru a na jednotlivé fáze tvorby RPM balíku.


Tvorba RPM balíků - pokračujeme

V minulých číslech Linuxových novin jsme si ukázali základní sekce spec-souboru. Nyní budeme pokračovat popisem skriptů, které ve spec-souborech mohou být.

Instalační skripty

Jak již bylo několikrát řečeno, RPM balík může obsahovat skripty, které se spustí před instalací balíku, po instalaci, případně před nebo po odinstalování balíku. Všechny tyto skripty dostanou od RPM proměnnou prostředí RPM_INSTALL_PREFIX udávající, do kterého adresáře se balík instaluje. Tato proměnná se použije pouze u balíků, které nemusí být instalovány v pevné adresářové struktuře (mohou bez problémů být například v /usr/local nebo v /opt. Příslušné skripty jsou ve spec-souboru uvozeny jedním z následujících slov podle toho, o který typ jde:

%pre
%preun
%post
%postun

Samozřejmě ne všechny čtyři skripty je nutno uvést. Tyto skripty jsou jen jako výpomoc pro případy, kdy nestačí pouze nainstalovat soubory daného balíku, ale je ještě potřeba udělat něco dalšího (například přidat resp. odebrat záznam z /etc/shells, jde-li o balík shellu).

Pokud upgradujeme daný balík, jsou spuštěny nejprve pre- a post-instalační skripty z nové verze, a potom teprve pre- a post-uninstall skripty ze starší verze, jak lze poznat například napsáním malého RPM balíku s testovacími výpisy v těchto skriptech:

# rpm -U a-2-2.noarch.rpm
Here is a pre v2 script 2.
Here is a post v2 script 2.
Here is a preun v1 script 1.
Here is a postun v1 script 1.

Jak rozpoznat instalaci od upgrade?

Často ve zmiňovaných skriptech chceme vykonat nějakou akci pouze v případě, kdy jde o první instalaci daného balíku (tedy nikoliv při upgradu). Příkladem může být přidání (pseudo)uživatele, kterého náš balík potřebuje ke své činnosti. V tomto konkrétním případě je sice možné podívat se do /etc/passwd, jestli tam už tento uživatel není, ale jsou i případy, kdy tato detekce není možná nebo je příliš náročná. Pro příklad nemusíme chodit daleko - stačí vzít post-uninstall skript, ve kterém chceme zrušit uživatele z /etc/passwd. Jak zjistit, jestli jde o skutečné rušení balíku, nebo jestli se jen post-uninstall skript volá proto, že je systém právě upgradován na novější verzi balíku? Systém RPM pro tento případ nabízí skriptům číselný argument (dostupný ze shellu jako $1), který říká, kolik instancí daného balíku bude v systému po dokončení akce nad aktuálním balíkem. V případě instalace tedy %post a %pre skripty dostanou parametr 1, zatímco v případě upgrade je parametr 2. Obdobně skripty %postun a %preun dostanou v případě upgrade parametr 1, zatímco v případě úplného rušení balíku parametr 0. Náš testovací balík z předchozího odstavce vypisuje parametr skriptu jako poslední slovo. Pokud tento balík odinstalujeme, dostáváme následující:

# rpm -e a
Here is a preun v2 script 0.
Here is a postun v2 script 0.

Verifikační skript

Tento skript, uvozený slovem %verifyscript je spouštěn v okamžiku kontroly daného balíku (rpm -V). Je zde možné například kontrolovat, jestli je správně konfigurace balíku, jestli je (například) náš shell uveden v /etc/shells, jsou-li vytvořeni příslušní uživatelé a podobně.

Verifikační skript, stejně jako čtyři předchozí skripty, je spouštěn programem /bin/sh. Pokud chceme mít skript v jiném programovacím jazyce, je možno použít přepínač -p interpret, například:

%pre -n /usr/bin/perl
print "Just another perl hacker.\n";

Spouště

Pod slovem v nadpisu se skrývá překlad anglického triggers. Z databází známe spouště jako procedury, které se spustí v okamžiku modifikace některé určité databázové položky. V RPM je tato vlastnost horkou novinkou (a není ani popsána v Maximum RPM). Podrobné informace se lze dočíst na adrese http://www.rpm.org/support/RPM-Changes-6.html.

Co jsou spouště a k čemu je lze použít? Jde o skript, který je součástí nějakého balíku, a který se spouští v případě, že systém RPM nějakým způsobem manipuluje (instaluje, upgraduje, ruší) s jiným balíkem. Ve zmiňované dokumentaci je příklad, kdy nějaký hypotetický poštovní klient má svůj symbolický link /etc/mymail/mymailer, který ukazuje na příslušný MTA (mail transport agent), nainstalovaný v systému. A jsou zde uvedeny dvě spouště - jedna pro balík sendmail http://www.sendmail.org a druhá pro vmailer http://www.porcupine.org/vmailer. A tyto skripty mají právě na starost vytváření onoho linku.

Tento příklad je dosti umělý, protože poštovní klienti umějí buďto SMTP, nebo umějí nový mail dát na vstup programu /usr/sbin/sendmail. A MTA zase obsahuje program, link nebo skript /usr/sbin/sendmail, který slouží pro odeslání pošty, a MTA umí i SMTP. Já jsem s úspěchem použil spoušť v balíku groff-latin2, kdy je potřeba modifikovat konfigurační soubor groffu. Takže mám skript, který toto udělá vždy, když je groff instalován nebo upgradován. Mechanismus spouští se vůbec dobře hodí pro balíky, které modifikují soubory, patřící jiným balíkům.

Jak se použije spoušť? Jde o shellovský (nebo i jiný) skript, uvozený jedním z následujících slov:

%trigger
%triggerin
%triggerun
%triggerpostun

Za tímto slovem jsou uvedeny přepínače (například -p interpret), následují dva mínusy (--) a pak specifikace tzv. "cílového" balíku, tedy balíku, pro který se má daná spoušť spustit. Specifikace má stejnou syntaxi jako tag Requires: v hlavičce spec-souboru. Můj balík groff-latin2 například má tuto spoušť:

%trigger -- groff

Složitější spoušť by mohla být uvozena takto:

%trigger -p /usr/bin/perl -- balík2 >= 2.1.117

Kdy se spoušť spustí?

  • %trigger
    • zdrojový balík se instaluje nebo upgraduje a cílový je již nainstalován. Spouští se po %post skriptu (nového) zdrojového balíku.
    • cílový balík se instaluje nebo upgraduje a zdrojový je již nainstalován. Spouští se po %post skriptu (nového) cílového balíku.
  • %triggerin
    • je ekvivalentní s %trigger
  • %triggerun
    • zdrojový balík se právě ruší nebo upgraduje a cílový je nainstalován. Spouští se před %preun skriptem (původního) zdrojového balíku.
    • cílový balík se ruší nebo upgraduje a zdrojový je nainstalován. Spouští se před %preun skriptem (původního) cílového balíku.
  • %triggerpostun
    • cílový balík se ruší nebo upgraduje a zdrojový je nainstalován. Spouští se po %postun skriptu (původního) cílového balíku.

V příští části si povíme o tom, jak vytvářet seznam souborů obsažených v RPM balíku a také o problematice maker.


Tvorba RPM balíků - pokračujeme

V minulém čísle jsme si přiblížili instalační skripty a spouště RPM balíků a v tomto čísle podrobně prozkoumáme další možnosti programu RPM.

Seznam souborů - sekce %files

Kromě popisu kompilace a instalace balíku, různých tagů a skriptů musíme ještě ve spec-souboru určit, které soubory k našemu balíku patří, případně jejich vlastnosti. Toto specifikujeme v sekci uvozené slovem %files. Syntaxe této sekce je jednoduchá. Na každém následujícím řádku je uvedena cesta k souboru, který se má do výsledného balíku uložit.

Pokud máme seznam souborů, které chceme do balíku zahrnout, již v nějakém souboru (například perl takový seznam pro své moduly umí vyrobit), můžeme za slovem %files uvést přepínač -f a specifikovat cestu k tomuto souboru:

%files -f /usr/lib/mypackage/file.list

Systém RPM pak do balíku uloží soubory uvedené v tomto seznamu a všechny soubory, jejichž jména následují na dalších řádcích za %files.

Kromě seznamu souborů mohou v této sekci být specifikovány i další parametry těchto souborů.

Dokumentační soubory

Již dříve bylo řečeno, že systém RPM považuje některé soubory v balíku za dokumentaci. Seznam všech souborů, patřících k dokumentaci balíku, lze vypsat příkazem rpm -qd. V sekci %files můžeme dokumentační soubor specifikovat tak, že jeho jménu předřadíme direktivu %doc:

%doc /usr/man/man1/gnomovision.1
%doc README COPYING

První řádek je jednoduchý: říká, že soubor /usr/man/man1/gnomovision.1 se má považovat za dokumentaci. RPM ovšem za dokumentaci automaticky považuje každý soubor, jehož jméno začíná /usr/man, /usr/X11R6/man, /usr/doc nebo /usr/info. Druhý řádek je zajímavější: pokud jméno %doc-souboru nezačíná lomítkem, RPM tento soubor hledá v adresáři, kde probíhala kompilace balíku, a tento soubor (nebo soubory) nainstaluje do adresáře se stejným jménem jako balík samotný do /usr/doc (například u balíku bash do /usr/doc/bash-1.14.7/).

Programu rpm můžeme kromě výše uvedených adresářů specifikovat i další adresáře jako dokumentační. Všechny soubory, které z těchto adresářů RPM zabalí do výsledného balíku, budou označeny jako dokumentace. Označení se provede direktivou %docdir adresář. Toto označení ovšem samo o sobě žádné soubory do balíku nevkládá. Příslušné soubory je nutno samostatně specifikovat dále v sekci %files.

Konfigurační soubory

Dalším speciálním typem souborů jsou konfigurační soubory. V předchozích částech tohoto seriálu jsme viděli, že RPM s takto označenými soubory zachází jinak než s běžnými soubory. Jako konfigurační lze soubor označit direktivou %config před jménem souboru:

%config /etc/sendmail.cf

Tato direktiva má ještě další variantu: do kulatých závorek lze uvést jedno nebo více slov z missingok a noreplace. První z těchto slov znamená, že daný konfigurační soubor nemusí existovat. Druhá direktiva říká, že RPM nemá příslušný soubor přepisovat (a ukládat pod jméno soubor.rpmsave). Pokud konfigurační soubor již existuje a má jiný kontrolní součet, než soubor obsažený v balíku, RPM nový soubor uloží pod jménem soubor.rpmnew. Tyto parametry jsou v RPM nově zavedené a nejsou popsány v knize Maximum RPM.

Atributy souborů

Korektně napsaný spec-soubor musí umožnit vytvořit balík nejen superuživateli, ale i běžnému uživateli. Prvním předpokladem pro to je (jak již bylo uvedeno), že sekce %install musí používat vlastnost BuildRoot. Druhým předpokladem je, aby atributy všech souborů byly přímo specifikovány ve spec-souboru. K tomu se používá direktiva %attr se třemi parametry: přístupová práva, vlastník a skupina. Například:

%attr(0644,root,root) %doc README
%attr(0644,root,root) %config(noreplace) \
	/etc/sendmail.cf
%attr(-,root,root) /usr/sbin/newaliases
%attr(4755,root,root) /usr/sbin/sendmail

Přístupová práva se specifikují numericky (oktalově), vlastník a skupina textově. U symbolických linků, kde přístupová práva nemají význam, se uvede znak minus.

Verifikace

Systém RPM umí verifikovat, jestli je balík nainstalovaný správně (pomocí kontroly přístupových práv, kontrolních součtů a verifikačního skriptu). Někdy ovšem nemusí tvůrce balíku chtít kontrolovat všechny atributy souboru. Například je-li soubor modifikován post-instalačním skriptem, neměla by probíhat kontrola času modifikace ani kontrolního součtu. K dosažení tohoto cíle se použije direktiva %verify, která říká, jaké atributy se mají kontrolovat. Maximální verze je následující:

%verify(owner group mode md5 size maj min symlink \
	mtime) /soubor

Tato kontrola je ovšem implicitní. Chceme-li některé kontroly vypnout, použijeme kratší seznam u %verify nebo použijeme slovo not:

%verify(not owner group mode) /dev/ttyS0
%verify(mode md5 size maj min symlink mtime) \
	/dev/ttyS0

Duchové

Jde o další horkou novinku nedokumentovanou v Maximum RPM. Soubor, který je označený jako %ghost, je vypisován jako patřící k danému balíku, ale při verifikaci se nekontroluje jeho existence.

%attr(-,root,root) %ghost /usr/man/man1/ssh.1

Adresáře

Uvedeme-li v seznamu v sekci %files jméno adresáře, RPM do výsledného balíku zabalí tento adresář i všechny soubory a adresáře v něm obsažené. Toto může, ale nemusí, být efekt, který požadujeme. Pokud chceme do balíku přidat jen adresář bez jeho podadresářů a souborů v něm obsažených, je nutno před jeho jméno předepsat direktivu %dir:

%dir /usr/X11R6/lib/X11/fonts/iso-8859-2/
/usr/X11R6/lib/X11/fonts/iso-8859-2/font1.pfa

/usr/X11R6/lib/X11/fonts/iso-8859-2/

První příklad zabalí do RPM balíku pouze adresář a jeden soubor v něm, druhý zabalí adresář i se všemi soubory. Pozor, pokud specifikujeme atributy (direktiva %attr), je nutno uvádět adresář a soubory v něm zvlášť. Adresář totiž má typicky práva 0755, zatímco běžné soubory mají obvykle 0644. Naštěstí RPM umožňuje do sekce %files napsat i řetězce obsahující hvězdičku. Druhý příklad by pak mohl mít tento ekvivalent (s lepší kontrolou přístupových práv):

%attr(0755,root,root) \
	%dir /usr/X11R6/lib/X11/fonts/iso-8859-2/
%attr(0644,root,root) \
	/usr/X11R6/lib/X11/fonts/iso-8859-2/*

Příště si povíme o makrech v RPM balících.


Tvorba RPM balíků - pokračujeme

Makra

V předchozích částech tohoto seriálu jsme viděli v činnosti některá makra (například %setup nebo %patch v sekci %prep). Nyní se na problematiku maker zaměříme detailněji.

Makro %setup a jeho možnosti

Toto makro má (jak víme) za úkol vzít zdrojový archív a rozbalit jej v adresáři BUILD. Předpokládá se, že vznikne adresář balík-verze, ve kterém budou všechny potřebné soubory. Ale co když zdrojový archív obsahuje jiný horní (top-level) adresář nebo se dokonce rozbaluje přímo do pracovního adresáře? Co dělat, pokud máme více zdrojových archívů (například X Window System má tři)?

  • -n adresář - tímto přepínačem makra %setup říkáme, že horní adresář se jmenuje jinak, než implicitní balík-verze.
  • -c - přepínač -c říká, že RPM má horní adresář vytvořit, přepnout se do něj a pak teprve začít rozbalovat archív Source0.
  • -D - makro %setup implicitně smaže horní adresář, pokud tento existuje. Máme-li ovšem více zdrojových archívů, musíme všem voláním makra %setup kromě prvního říct, aby tento adresář nebyl smazán. Dosáhneme toho právě přepínačem -D.
  • -T - neřekneme-li jinak, makro %setup rozbalí archív Source0. Pokud je tento archív již rozbalen (například v dalších voláních tohoto makra), je nutné uvést přepínač -T.
  • -a číslo
  • -b číslo - rozbalí zdrojový archív Sourcečíslo. Přepínač -a (after) provede rozbalení až po přepnutí se do adresáře BUILD/balík-verze (nebo jiného), přepínač -b (before) toto provede před přepnutím se do tohoto adresáře, čili v adresáři BUILD.

Příklad

Máme-li dva zdrojové archívy, můžeme mít ve spec-souboru například toto:

...
Source0: balík-1.0.tar.gz
Source1: balík-fonts-1.0.tar.gz
...
%prep
%setup
%setup -T -D -a 1
...

Makro %patch - aplikace záplat

Makro %patch akceptuje podobné přepínače, jako program patch. Navíc je zde pouze specifikace toho, který soubor se má použít. Následující dva řádky jsou ekvivalentní a aplikují soubor, uvedený v hlavičce jako Patch2:

%patch2
%patch -P 2

Kromě velkého -P toto makro akceptuje ještě přepínače -s, -E, -pN a -b suffix.

Větvení

RPM je ideální nástroj pro generování balíků pro různé architektury a různé operační systémy z jednoho konfiguračního souboru. Svět ale není ideální, a proto je někdy potřeba upravit běh kompilace nebo vlastnosti balíku pro daný systém nebo danou architekturu. V kterémkoli ze skriptů nebo v sekci %files lze říct, že určitá část platí pouze pro některou architekturu nebo operační systém. K tomu lze použít direktivy %ifarch a %ifos (případně %ifnarch a %ifnos), s dalšími direktivami %else a %endif. Význam je intuitivně jasný, proto uvedu jen příklady. V sekci %prep například může být:

...
%ifarch alpha sparc64
%patch4 -p1 -b .64-bit
%endif
...

Podobně je možné v sekci %files zařadit nebo nezařadit určité soubory do distribuce podle konkrétní architektury nebo operačního systému.

Uživatelská makra

Ve spec-souboru si uživatel může definovat i svá vlastní makra pomocí syntaxe %define makro hodnota. Makro lze použít pomocí znaku procento jedním ze dvou ekvivalentních způsobů:

%makro
%{makro}

RPM má dvě předdefinovaná makra: %PACKAGE_VERSION a %PACKAGE_RELEASE. Tato makra umožní mít verzi balíku pouze na jednom místě a psát následující text:

...
Version: 1.2.26
Source0:\
  ftp://.../.../ssh-%{PACKAGE_VERSION}.tar.gz
Source1:\
  ftp://.../.../ssh-%{PACKAGE_VERSION}.tar.gz.sig
...

Více balíků v jednom souboru?

Někdy je vhodné rozdělit soubory, které vzniknou například překompilováním zdrojového tar.gz archívu, do více balíků. Jde-li například o knihovnu, vytvářejí se typicky dva balíky. V jednom z nich je sdílená knihovna plus případná obecná dokumentace, konfigurační soubory a podobně, a ve druhém (obvykle nazvaném knihovna-devel je statická verze knihovny a její hlavičkové soubory). Nebo například u síťové aplikace lze mít zvlášť balík serveru a zvlášť klienta.

Systém RPM umožňuje takovéto balíky vytvářet najednou, to jest z jednoho zdrojového archívu a jednoho spec-souboru. Výsledkem je kromě několika binárních RPM souborů jen jeden zdrojový (src.rpm) RPM-soubor.

Z jednoho zdrojového RPM souboru lze tedy vytvářet více binárních tzv. sub-balíků (sub-packages). Každý takovýto balík by měl mít ovšem svoji hlavičku (tagy Summary, Group a další). Hlavičku sub-balíku uvedeme do spec-souboru za direktivu %package:


...
Name: libpenguin
Summary: The Penguin library
Group: Penguins/Libraries
...
%package devel
Group: Development/Penguins
Summary: The Static Penguin library\
    and its header files
...
%package -n penguin-builder
Group: Development/Penguins
Summary: The Penguin User Interface Builder
...

Výsledkem by pak byly balíky libpenguin-verze-release.arch.rpm, libpenguin-devel-verze-release.arch.rpm a penguin-builder-verze-release.arch.rpm. Pokud chceme vytvořit sub-balík s úplně novým názvem (bez prefixu z hlavního balíku), použijeme direktivu %package -n jméno.

Každý sub-balík musí mít svůj tag Group a Summary. Ostatní tagy lze zdědit z hlavního balíku. Kromě toho musí být pro každý sub-balík uvedena sekce %description (uvádí se se stejným argumentem jako direktiva %package, včetně flagu -n):


%description devel
...
%description -n penguin-builder

Podobně je možné uvádět speciální pre- a post-instalační skripty a spouště pro jednotlivé balíky:

%post -n penguin-builder
...
%trigger devel -- penguin-builder
...

I sekce %files je pak rozdělena na část hlavního balíku a část sub-balíků. Pokud sekci %files pro daný sub-balík neuvedeme vůbec, RPM daný binární RPM soubor nevytvoří (uvedeme-li sekci %files prázdnou, vytvoří se RPM soubor, který neobsahuje žádné soubory, jen hlavičku a případné skripty). Takže umístíme-li tuto sekci do větvení, můžeme sub-balík vytvářet jen pro některé architektury:

%ifarch alpha
%files alpha-fix
/usr/bin/foobar-alpha-fix
%doc README-alpha-fix
%endif

Závěr

Tím končí seriál o RedHat Package Manageru, systému RPM. Snažil jsem se v tomto seriálu se aspoň dotknout každé problematiky, která se týká používání tohoto systému a tvorby balíků v něm. Podrobnější informace o RPM lze nalézt v knize Maximum RPM, na WWW stránkách RPM http://www.rpm.org nebo v diskusním listu, zaměřeném na systém RPM rpm-list@redhat.com. Archív listu je dostupný na adrese http://archive.redhat.com/rpm-list/.


 
Pocet navstev: 94617