Vytváření RPM balíků |
Jan Kasprzak, 12. června 1998 |
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.
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.
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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
|