V minulém čísle našeho seriálu o systému RPM jsem začal detailně popisovat formát spec-souboru, který řídí vytváření RPM balíku. Vysvětlil jsem, jaký význam mají jednotlivé tagy v hlavičce souboru, a nyní budu pokračovat výkladem o dalších sekcích spec-souboru. Některé sekce jsou povinné, jiné nepovinné. Sekce začíná znakem % a svým názvem na začátku řádku. Pořadí sekcí ve spec-souboru není definováno - zde budou jednotlivé sekce uvedeny v jakémsi logickém uspořádání.

Se sekcí %description jsme se už setkali. Tato sekce je povinná a obsahuje textovou informaci o určení a použití balíku. Tuto sekci využívá například instalační program Red Hat Linuxu, když se klávesou F1 dotážeme na podrobnější informace o balíku.

Další sekce je nazvaná %changelog a jak již její název praví, zachycuje protokol o změnách ve spec-souboru (nikoli tedy v softwaru samotném. Jednotlivé záznamy začínají hvězdičkou na první pozici řádku, následuje datum a jméno člověka, který změnu provedl. Na dalších řádcích pak může být popis změny. Příklad části sekce %changelog z balíku ssh je na výpisu Příklad sekce changelog.

* Thu Jun 11 1998 Jan "Yenya" Kasprzak <kas@fi.muni.cz> - updated to 1.2.25. - fixed truncated .pam patch. - built on RedHat 5.1 (and tested upgrade on 5.0 too). * Wed May 20 1998 Jan "Yenya" Kasprzak <kas@fi.muni.cz> - Updated to 1.2.23: - removed the -NYP patch (no longer necessary). - removed the -tmpfile patch (no longer necessary). - added %post scripts linking the ssh*1 binaries and manpages as ssh* if no such links exist. This will allow a coexistence of ssh1 and ssh2 RPMs on one system.

Sekce %prep

test -r /etc/ssh/ssh_host_key && ssh-keygen blabla

Namísto toho je nutné použít následující ekvivalent:

if test -r /etc/ssh/ssh_host_key;
	then ssh-keygen blabla; fi

Skript z této sekce, stejně jako ostatní skripty, má k dispozici některé speciální proměnné prostředí. Uvádím je zde spolu s příklady hodnot nebo s implicitními hodnotami:

• RPM_SOURCE_DIR=/usr/src/redhat/SOURCES - adresář, ve kterém jsou uloženy zdrojové archivy a záplaty. Skript %prep odsud může rozbalovat tyto archivy a aplikovat záplaty.
• RPM_BUILD_DIR=/usr/src/redhat/BUILD - adresář, ze kterého je skript spuštěn. Sem se pak rozbalí jednotlivé zdrojové archivy a zde probíhá kompilace.
• RPM_DOC_DIR=/usr/doc - adresář, do kterého se ukládá dokumentace k balíku.
• RPM_ARCH=i386 - architektura, pro kterou se aktuální balík vytváří.
• RPM_OS=Linux - operační systém, pro který se aktuální balík vytváří.
• RPM_OPT_FLAGS="-O2 -fno-strength-reduce -m486" - optimalizační přepínače pro kompilátor jazyka C.
• RPM_BUILD_ROOT=/tmp/ssh-root - specifikace adresáře BuildRoot.
• RPM_PACKAGE_NAME=ssh - jméno balíku.
• RPM_PACKAGE_VERSION=1.2.25 - verze softwaru.
• RPM_PACKAGE_RELEASE=1i - verze RPM balíku.

Makra

  %prep
  %setup
  %patch -p1

Makro %setup vezme zdrojový archiv, uvedený v hlavičce jako Source, resp. Source0, rozbalí jej do adresáře BUILD, změní vlastníka všech souborů na superuživatele (to pouze v případě, že balík vytváří superuživatel) a nastaví bity r a x pro všechny uživatele.

Makro %patch aplikuje záplatu, uvedenou v hlavičce jako patch, resp. patch0. Přepínač -p1 z našeho příkladu je předán programu patch(1).

Skript %prep samozřejmě nemusí sestávat pouze z volání maker %setup a %patch. Může obsahovat i další příkazy, například je-li program konfigurován pomocí systému GNU autoconf a modifikujeme-li konfigurační soubor configure.in, můžeme v této sekci přegenerovat skript configure příkazem autoreconf (tuto konstrukci naleznete mimo jiné i ve spec-souboru Secure Shellu - tam se přidává podpora pro PAM do configure.in, a musí se tedy přegenerovat configure. Kromě toho makra mohou mít i parametry, kterými se specifikují další vlastnosti. K těmto vlastnostem se vrátíme v dalším díle našeho seriálu.

Sekce %build - kompilace softwaru

  %build
  ./configure
  make CFLAGS="$RPM_OPT_FLAGS" all

Příkazu configure, pokud jej program podporuje, můžeme samozřejmě dávat i další parametry (třeba --with-gcc --prefix=/usr). Tohle je vůbec dost diskutabilní věc: podle Linux Filesystem Hierarchy Standard (FHS, dříve FSSTND) by lokálně instalovaný software měl být instalován do adresáře /usr/local, zatímco software, který patří k systému samotnému by měl být v /usr. Ovšem je software, který zabalíte do RPM a distribuujete, součástí systému, nebo je spíš blíže lokální instalaci? Můj názor na tuto problematiku je ten, že /usr/local bylo zavedeno proto, aby bylo možné ty lokálně instalované věci odlišit. Ale máme-li RPM, máme na odlišení jiné a lepší prostředky (například položku Distribution nebo Packager v hlavičce RPM balíku). Moje RPM balíky se tedy instalují přímo do systémových adresářů, nikoliv do /usr/local.

Sekce %install - instalace softwaru

  %install
 mkdir -p ${RPM_BUILD_ROOT}/usr/{bin,lib,man/man1}
 make prefix="${RPM_BUILD_ROOT}/usr" install

Je dobré vědět, že ne všechny programy jsou schopny být kompilovány s jiným prefixem, než se kterým jsou pak instalovány. V takových případech nezbude než ručně zjistit, co přesně dělá příkaz make install, a jeho činnost pak nasimulovat v sekci %install s příslušným BuildRoot. U některých balíků je i tento postup příliš náročný, a proto se instalují přímo na místo určení. Takovýto balík pak ovšem může rekompilovat jen superuživatel. Příkladem takového balíku je například tetex.

Pokud balík nepoužívá BuildRoot, je podstatně náročnější jej odladit. Takovéto ladění a pokusná instalace by měly probíhat na jiném počítači, než vlastní kompilace. Může se totiž stát (a je těžké to odhalit), že do balíku zapomeneme přibalit některý důležitý soubor. Na původním počítači vše funguje, protože tento soubor tam zbyl po make install. Jinde balík ale selže.

Sekce %clean - smazání meziproduktů

V příští části tohoto seriálu se dozvíme, jak specifikovat soubory patřící k balíku a jaké další skripty mohou ve spec-souboru být.