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

• --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

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.