Toto Howto bylo napsáno s cílem pomoci lidem vytvářet softwarové balíčky, které lze začlenit do distribuce Mandriva Linuxu. Důraz bude kladen na odlišnosti rpm balíčků Mandriva Linuxu od jiných distribucí využívajících rpm. Tento dokument by měl být užitečný vývojářům Mandriva Linuxu, stejně jako ostatním lidem. Příspěvek s pokročilejšími informacemi je k dispozici na stránkch Development/Howto/RPM_Advanced.

Distribuce GNU/Linuxu Mandriva Linux je vytvářená a vydávaná firmou Mandriva, Inc., za pomoci různých spolupracovníků, testerů a překladatelů. Někteří z nich jsou uvedeni v Distro Credits.

V tomto dokumentu se předpokládá, že čtenář se umí v linuxu orientovat. Zná základní příkazy, adresářovou strukturu a má zvládnutou přinejmenším instalaci rpm balíčků.

Tento dokument je koncipován jako návod krok za krokem k získání rpm balíčku, který se hladce začlení do distribuce GNU/Linux Mandriva Linux, buď z předchozího zdrojového rpm nebo ze zdrojového souboru tar.

Nemáte-li na to, měli by jste číst Cooker participate howto, angl., který vysvětlí, jak se lze podílet na vývojovém procesu Mandriva Linuxu.

RPM může označovat tři věci:

• program určený k instalaci nebo tvorbě balíčků,
• formát použitý v balíčcích (zdrojových nebo binárních) vytvořených programem rpm,
• soubor označovaný také jako balíček, obsahující buď binární nebo zdrojové kódy společně s information header (více viz popis formátu souboru rpm) o tom, jak instalovat a odinstalovat program.

Program rpm je z pohledu uživatele výkonný správce balíčků. Funguje jako „dirigent“ při jakékoli práci s rpm balíčky. Mimo jiné může:

• instalovat nebo aktualizovat balíčky s kontrolou závislostí
• během instalace provádí akce nutné k zajištění funkčnosti instalovaného programu
• obnovuje omylem smazané soubory patřící k balíčku
• vypíše, je-li balíček již instalován
• zjistí, ke kterému balíčku patří jednotlivý soubor
• ověří současnou instalaci, nakolik jsou naplněny požadavky instalovaných balíčků na závislé balíčky…

Z programátorského hlediska je program rpm balíček, který obsahuje v jediném rpm souboru všechny informace potřebné k instalaci programu pro danou platformu.

Je důležité od počátku rozlišovat rozdíly mezi zdrojovým rpm balíčkem (*.src.rpm) a binárním (*.<architektura>.rpm) balíčkem.

První (*.src.rpm)obsahuje kompletní zdrojový strom od původního programátora plus všechny dodatečné balíčky přidané za účelem konfigurace, kompilace a instalace programu. Obecně vzato skládá se ze souboru spec (soubor říkající programu rpm, které operace se musí vykonat za účelem vytvoření balíčku) a záplat, pokud existují.

Druhý typ souboru (*.<architektura>.rpm) obsahuje binární kompilační program a všechny soubory (dokumentace, konfigurační soubory, ikony,…) které budou instalovány na cílový systém. Také obsahuje proceduru, které zajistí uloženi souborů na správná místa a akce, které se musí vykonat, aby byl program funkční.

Původně byl program rpm navržen pro práci v Red Hat Linux, ale pracuje i v dalších distribucích založených na rpm: Mandriva Linux, Suse atd.; rpm je již na těchto systémech nainstalován.

Můžete získat vanilla rpm distribuci od Red Hatu zde.

Budete-li binární rpm budete sestavovat pro Mandriva Linux, nemusí správně fungovat v dalších distribucích, přestože Mandriva dělá maximum pro kompatibilitu s Red Hat.

Tvorba balíčků pro Cooker (tedy vývojovou verzi Mandriva Linuxu) je vždy náchylná k malým záplatám a vylepšením používaného programu rpm. Otevřete jakékoli zrcadlo Mandriva Cooker a získáte:

• balíček rpm od Red Hatu s našimi záplatami.
• balíček rpm-build obsahující scripty používané k tvorbě balíčků
• balíček spec-helper, pracovní nástroj pro minimalizaci specfiles, zajišťující automatické činnosti jako např. stripping binárek a komprimaci manuálových stránek.
• balíček libtool používaný ke konfiguraci scriptů určených ke tvorbě sdílených knihoven.
• balíček rpmlint zajišťující kontrolu platnosti vygenerovaného src.rpm souboru.

Pro tvorbu rpm balíčků musíte mít nainstalovánu příslušnou sadu programů. Pro pokyny k instalaci viz Installing and removing software (nebo návody na této wiki).

K sestavování balíčků potřebuje program rpm speciální adresářový strom ve vašem domovském adresáři. Tento strom může být vytvořen následujícím příkazem (na jednom řádku):

 mkdir -p ~/rpm/{BUILD,RPMS/$ARCH,RPMS/noarch,SOURCES,SRPMS,SPECS,tmp} 

Přepište řetězec $ARCH na označení architektury, pro kterou budete balíčky připravovat. Základní jsou i586, ale může být také x86_64/sparc/alpha/ppc.

Poznámka! Tvorba rpm balíčků pod rootem je nebezpečná, protože binární balíčky jsou nainstalovány do systému dříve, než jsou zabaleny do balíčku. Nechcete-li kompromitovat svůj systém, vytvářejte balíčky vždy jako normální uživatel.

Ujistěte se, že adresářový strom má tento tvar:

~/rpm/BUILD: adresáře vytváření

~/rpm/RPMS: obsahuje adresáře pro každou architekturu, které budou obsahovat binární balíčky

~/rpm/RPMS/i586: adresář pro uložení balíčků pro procesory i586. (Pozn. překl: tento adresář mi výše uvedený příkaz nevytvořil)

~/rpm/RPMS/x86_64: adresář pro uložení balíčků pro procesory AMD64 (Pozn. překl: tento adresář mi výše uvedený příkaz nevytvořil)

~/rpm/RPMS/noarch: totéž pro noarch balíčky (bez závislosti na procesoru) (Pozn. překl: tento adresář mi výše uvedený příkaz nevytvořil)

~/rpm/SOURCES: zdrojové soubory (např. mujbalicek.tar.bz2)

~/rpm/SPECS: spec soubory, ty musí být nejprve vytvořeny

~/rpm/SRPMS: zdrojové rpm po tvorbě balíčku

~/rpm/tmp: adresář pro dočasné soubory během tvorby balíčku

Poznámka: Adresářová struktura po ~/rpm/RPMS je pro rpm nezbytná. Jestliže neexistuje, obdržíte chybové hlášení.

K tvorbě balíčků potřebujete mít v domovském adresáři konfigurační soubor .rpmmacros.:

%_topdir                %(echo $HOME)/rpm 
%_tmppath               %(echo $HOME)/rpm/tmp
# If you want your packages to be GPG signed automatically, add these three lines
# replacing 'Mandrivalinux' with your GPG name. You may also use rpm --resign
# to sign the packages later.
%_signature             gpg
# _gpg_name obsahuje jméno zadané při vytváření GPG klíče
%_gpg_name              Mandrivalinux
%_gpg_path              ~/.gnupg
# Add your name and e-mail into the %packager field below. You may also want to
# also replace vendor with yourself.
%packager               John Doe  <foo@mail.invalid> 
%distribution           Mandriva Linux 
%vendor                 Mandriva 
# If you want your packages to have your own distsuffix instead of mdv, add it
# here like this
#%distsuffix             foo 

Varujeme před změnou nastavení parametru %optflags, které je nastaveno pro váš systém v /usr/lib/rpm/mandriva/rpmrc.

Program rpm převezme nastavení pro tvorbu balíčků. Vše výše uvedené může být provedeno v jednom kroku (pro i586) spuštěním RPM Setup Scriptu. (Pozn. překl.: Tento script se musí spustit s rootovským oprávněním; soubory ~/.rpmrc a ~/.rpmmacros jsem musel dodatečně editovat. Stačí okopírovat příslušnou část ze scriptu do příslušného souboru)

Toto je obecný příklad pro balíčky, které jsou již v distribuci obsaženy.

Nejnovější rpm soubory z repozitáře COOKER jsou dostupné na mnoha zrcadlech, jejichž seznam je k dispozici v Cooker Mirrors. Tam najděte v podadresáři SRPMS zdrojový rpms (main, contrib, jpackage, others) a dále cpu architekturu (např. i586, x86_64,…):

media/main pro binární rpms repozitáře main

media/contrib pro binární rpms repozitáře contrib

media/jpackage pro binární rpms bez závislosti na architektuře.

Když najdete zdrojový rpm který chcete upravit pro Mandriva Linux, stačí spustit příkaz

 rpm -ivh mujbalicek.src.rpm 

Tím nainstalujete všechny zdrojové soubory do vašeho rpm adresářového stromu. Můžete také nastavit urpmi ke stažení zdroje ze zrcadla.

 [camille@kenobi ~/rpm]$ rpm -i /cooker/SRPMS/
ktron-1.0.1-2mdk.src.rpm 
[camille@kenobi ~/rpm]$ ls -R *
SRPMS:
SPECS:
ktron.spec
SOURCES:
ktron-1.0.1.tar.bz2
RPMS:
noarch/ i686/ i586/ i386/
BUILD: 

Ve výpisu vidíme, že rpm nainstaloval do našeho adresářového stromu pro tvorbu rpm zdrojový soubor ktron-1.0 a soubor spec. Ještě před tvorbou balíčku novější verze může být pro vás přínosem, jestliže si znovu vytvoříte balíčky současných verzí, abys lépe rozuměl jak je balíček sestaven a kompilován. Magický příkaz pro sestavení balíčku je rpmbuild s volbou buildall:

[camille@kenobi ~/rpm]$ cd ~/rpm/SPECS
[camille@kenobi ~/rpm]$ rpmbuild -ba ktron.spec
[camille@kenobi ~/rpm]$ ls -l ~/rpm/RPMS/i586/ktron-1.0.1-2mdk.i586.rpm
[camille@kenobi ~/rpm]$ ls -l ~/rpm/SRPMS/ktron-1.0.1-2mdk.src.rpm 

Jakmile je tvorba u konce (v případě některých velkých balíčků jako je například kernel může trvat celé hodiny) bez chyb, získáte binární rpm a src.rpm v podadresáři ~/rpm/RPMS/i586 respektive ~ /rpm/SRPMS/ . Pokud chcete instalovat binární rpm, musíte se přihlásit jako root, například pomocí příkazu su (a odhlášení klávesovou zkratkou Ctrl+d). Pro účely tvorby balíčků rpm a src.rpm nikdy nepotřebujete být root.

Logovací záznamy o tvorbě balíčku mohou být velmi dlouhé a lze je ukládat pro pozdější prohlížení. Já používám emacs nebo xemacs a použiju druhé okno se shellem (Alt-x shell) a uložím buffer jako ktron. LOG, například, po dokončení.

V podadresářích ~/RPM/BUILD obvykle potřebujete zpřístupnit záplaty ke zdrojovým souborům (existuje-li jedna nebo více záplat, byly uloženy v ~/rpm/SOURCES), k binárkám, zkompilovaným knihovám, man stránkám atd. Soubor spec popisuje zdroje a soubory se záplatami a jak sestavit balíček a jak celou sadu správně nainstalovat.

Nyní si vysvětlíme, co vše je potřeba udělat, aby v případě vylepšení balíčku ktron byl správně upraven soubor spec a pak znovu vytvořen balíček.

Je důležité si uvědomit, že každý balíček udržovaný v Mandrivě je uložen v CVS systému. To umožňuje zaznamenávat všechny změny v balíčku tak, aby se vývojář mohl kdykoli podívat do archívu a zkontrolovat předchozí modifikace a je li to nutné, vrátit se ke starší verzi.

Každý soubor spec je uložen v modulu volaném SPEC/<balíček> nebo contrib-SPEC/<balíček>. Jsou přístupné na stránkách mandrivy.

Pro další detailní informace o přístupu do CVS systému nahlédněte na stránku Mandriva Linux CVS.

Najdete-li na příklad na Freshmeat nebo Sourceforge zajímavý program, který upozorní, že čaj je hotový, můžete chtít zpřístupnit ho všem uživatelům Mandriva Linuxu, kteří rádi pijí čaj. Nejlepším způsobem je nejspíš vytvořit pro něj rpm balíček podle standardů Mandrivy.

Stáhněte tarball a uložte jej v adresáři SOURCES.

Licence

Dnes převažuje GPL licence, nicméně existuje i sada v současnosti používaných ne-GPL licencí. Pečlivě zkontrolujte licenci software a ujistěte se, že je možné včlenit program do distribuce. Nelze přijmout uzavřený (ne open source) software, některé vyjímky existují pro klub. Také nemůžeme přijmout program, jehož licence neumožňuje volnou distribuci. Dávejte na takové programy pozor. Seznam přijatelných licencí lze nalézt na stránce Mandriva Licences.

Komprimace tarballu

S ohledem na minimalizaci práce se doporučuje použít původní tarball bez jakýchkoli modifikací. Jsou-li zdrojové soubory poskytované ve více různých komprimačních formátech, obvykle volíme .tar.bz2. Vyhýbejte se komprimaci záplat v textových formátech (vytvořené např. programem diff a podobnými) a další konfiguračních záznamů / script (textových souborů), které obvykle zabírají malý prostor, zatímco komprimace komplikují kontrolu změn v Subversion diffs (a Subversion také používá nějakou formu komprimace). Poznámka: Z bezpečnostních důvodu důrazně doporučujeme u balíčků s vysokým bezpečnostním rizikem neupravovat původní zdrojový soubor, bude-li to měnit kontrolní součet (checksum) souboru. Pro tyto druhy balíčků doporučujeme ponechat původní formu (formát) souboru tak, aby kdykoli bylo možné pomocí md5sum/gpg porovnat hodnoty s těmi, které jsou uvedeny na stránkách poskytovatele programu uvedených v sekci download. Jedním příkladem, kde lze využít vyjímky byl např. OpenSSH.

A jsme u nejdůležitější části tohoto dokumentu. Soubor spec obsahuje všechny informace potřebné pro rpm, aby:

• mohl sestavit program a vytvořit zdrojový a binární rpms,
• instaloval a odinstaloval program z počítače konečného uživatele.

Skutečnost, že tyto informace jsou spojené v jedné řadě za sebou může být pro začátečníka matoucí. Ve skutečnosti lze totéž vidět ve zdrojovém tar stromu, který tyto informace již obsahuje. Během instalační procedury jsou vyjmuty a spuštěny příkazem make install do zdrojového stromu, obě části jsou pevně provázané.

Stručně řečeno, soubor spec popisuje „simulovanou“ kompilaci a instalaci, řekne programu rpm které soubory vzniké tímto „instalováním“ jsou zabalené a jak mají být nakonec nainstalovány do uživatelského systému. Příkazy jsou provedeny prostřednictvím shellu /bin/sh např. jako [-f configure.in]&& autoconf jsou platné.

Tato část není určena k podrobnému vysvětlení všech vlastností souboru spec. Kniha MaximuRPM (viz Section 7) popisuje detaily. Vše co se nyní chystáme udělat, je rychlý přehled vlastností použitých v jednom běžném vzorovém souboru spec v Mandrivě.

Příklad je vzat z repozitáře Cooker. Můžete to považovat za naši šablonu spec souboru určenou pro spouštění one from scratch.

Budete-li vytvářet další a další balíčky rpm, zjistíte, že existují různé volby, o kterých vám nemůžeme nic říci. RPM je extrémně rozšiřitelné, takže nalezení všech možností necháme na čtenářích za domácí cvičení. Dobrý způsob, jak se dozvědět více je projít nějaké soubory spec a podívat se, jak jsou vytvořeny. Příklady spec souborů můžete vidět zde

%define name    gif2png
%define version 2.0.1
%define release %mkrel 1
Name:           %{name} 
Summary:        Tools for converting websites from using GIFs to using PNGs
Version:        %{version}
Release:        %{release}
Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2
Source1:        %{name}-%{version}-mdk-addon.tar.bz2
Patch0:         gif2png-2.0.1-bugfix.patch.bz2
URL:            http://www.tuxedo.org/~esr/gif2png/
Group:          Applications/Multimedia
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot
License:        MIT-like
Requires:       python 
%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files 
to PNG files. The Python script web2png converts an entire web tree, also 
patching HTML pages to keep IMG SRC references correct.
%prep
%setup -q -a 1
%patch -p1
%build
%configure
%make
%install
rm -rf $RPM_BUILD_ROOT
%makeinstall
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(0755,root,root)
%doc README NEWS COPYING AUTHORS
%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*
%{_bindir}/gif2png
%{_bindir}/web2png
%changelog
* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-1mdk
- Upgraded to 2.0.1
* Mon Oct 25 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.0-1mdk
- Specfile adaptations for Mandrake 
- add python requirement
- gz to bz2 compression 

Nyní si podrobněji rozebereme každý řádek z tohoto souboru:

Upozorňujeme, že znak % na začátku řádku může mít různý význam:

• začátek sekce (prep, build, install, clean)
• vestavěný shellový script s makry (setup, patch)
• příkazy používané v některých sekcích (defattr, doc,…)

%define name    gif2png
%define version 2.0.1
%define release %mkrel 1 

Tyto odkazy definují konstanty, které mohou být použity v mnoha sekcích souboru spec, volané jménem %{jméno}, %{verze} a %{verze}. %mkrel je makro Mandrivy, které je používáno pro přidání písmen mdv za číslo verze, viz Distro Specific Release Tag.

Nyní se můžeme začít zaobírat jednotlivými položkami pro rpm:

Name:           %{name}

Jméno balíčku, které bude použito v databázi balíčků na počítači uživatele.

Povšimněte si, že v tomto případě jde o odkaz na konstantu „name“, definovanou v předchozí sekci.

Version:        %{version}
Release:        %{release}

Na tomto místě musíme vysvětlit, jak se jméno balíčku vytváří. Je důležité respektovat standardy, aby byla vaše práce pochopitelná pro ostatní.

Existují i některé značky (tagy), které by bylo užitečné znát, ale které nejsou ve vzorovém souboru spec použity, ale na které je možné někdy narazit. Nelze očekávat, že si je budete pamatovat všechny, pokud s vytvářením rpm balíčků začínáte, a později je užitečné vytvořit si jejich seznam.

Binární balíček je pojmenován takto: jméno-verze-vydání.arch.rpm

Zdrojový balíček je pojmenován následovně: jméno-verze-vydání-src.rpm (např. gif2png-2.0.1-1mdk.src.rpm z našeho příkladu)

Jméno je obvykle zvoleno podle názvu hlavního binárního balíčku, ačkoli postačujícím důvodem může být i známost jiného názvu.

Verze je číslo z nezaplátovaného zdroje. Jde o číslo verze z jméno v původním komprimovaném souboru: jméno-verze.tar.gz.

Vydání (release) je číslo následované písmeny mdv (znamenající „Mandriva“; toto je naprosto nezbytné) je přírustkové číslo zvyšující se o jednu při každém dalším sestavení balíčku. Sestavení se může opakovat kvůli záplatě použité na zdroj, úprava souboru spec, přidání ikona atp.

 Summary: tools for converting websites from using GIFs to using PNGs 

Tento řádek obsahuje jednořádkový popis balíčku.

 Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 

Tento řádek říká, který zdrojový soubor byl použit pro vytvoření rpm balíčku. Všimněte si, že před jménem souboru předchází kompletní URL (není povinné), ukazující kde je původní zdroj k dispozici.; program rpm tuto URL odstraní, uchová čistý název souboru a vyhledá ho v adresáři SOURCE. Pokud říkáme, že kompletní URL není povinné, je nutné zdůraznit, že je vysoce doporučené, aby ostatní mohli zdrojové soubory najít, snadno provést aktualizaci nebo novou kompilaci. Také to umožní nástrojům jako je rpmbuildupdate provést automatické zkompilování nové verze (viz rpmbuildupdate pro další informace.

Existuje-li více než jeden zdrojový soubor, použijí se další řádky s označením Source1:…, Source2:…, atd.

Patch0:         gif2png-2.0.1-bugfix.patch.bz2

Pro existenci tohoto nepovinného tagu existují dva důvody:

1. použili jste na zdrojový soubor patch (záplatu), která musí být použita před kompilací (sestavením balíčku). Všimněte si, že všechny patche jsou také komprimované ve formátu bzip2. I když nějaký patch je tak malý, že nemá smysl ho kopírovat, musí být převeden do uvedeného formátu.
2. Byli jste upozorněni na patch pro verzi vašeho software někte na síti a stáhli jste si ho.

Mějte na paměti, že soubor s patchem musí být umístěn do adresáře SOURCES; ve zdrojích může být i více záplat, pak musí být pojmenovány Patch1, Patch2 atd.

URL:            http://www.tuxedo.org/~esr/gif2png/ 

Další nepovinný, ale vysoce doporučený řádek. Uvádí domovskkou stránku (home page) programu.

Group:        Multimedia

Určuje, ve které skupině programů bude tento program umístěn. Tato vlastnost je využívaná správci balíčků jako je např. rpmdrake nebo kpackage.

Kompletní struktura skupin, kterou lze použít, se liší od Red Hatu, lze ji najít na stránkách RPM Groups. Tento údaj je povinný. Při vynechání se může váš balíček zamíchat mezi jiné s odlišným určením ve skupinách využívaných Mandriva Linux installerem nebo v grafickém správci balíčků.

BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-buildroot 

Tento řádek nesmí být vynechán, je velmi důležitý. Programu rpm říká, že instalovaný program použije konkrétní kořenový adresář (fingovaný “/“) na počítači, kde je kompilován. Jsou k tomu dva důvody:

1. vytváříte-li balíčky rpm a nemáte oprávnění roota, nemůžete instalovat sadu programů v obvyklých adresářích.
2. Nainstalování do pracovního stromu může smíchat soubory z balíčků s jinými.

Nejdůležitější je však to, že to může vyvolat bezpečnostní riziko. Mnoho lidí používá pro buildroot adresář /var/tmp nebo /tpm. Není to důležité, pokud jste jediný uživatel počítače, ale pokud máte více uživatelů, kteří sestavují stejný balíček ve stejnou dobu, rpm bude blít (Pozn. překl.: angl. barf, zvracet - ponechal jsem pro radost). Proto je důležité definovat %{_tmppath} uvnitř vašeho domovského adresáře!

 License:    MIT-like

Definice licence kterou vybral autor a která bude použita pro zabalený balíček. Většinou jde o GPL. Kompletní seznam schválených licencí najdete na stránkách Mandriva Licenses a Licensing Policy.

 Requires:       python 

Řádek byl přidán, protože jeden z programů obsažených v balíčku je script pythonu. Takže je zapotřebí python, který ho vykoná. Můžete zadat nepovinné minimum (nebo konkrétní verzi), například:

Requires:python>=1.5.1
%description
Tools for converting GIFs to PNGs. The program gif2png converts GIF files
to PNG files. The Python script web2png converts an entire web tree, also
patching HTML pages to keep IMG SRC references correct.

Tento tag je vcelku zvláštní, protože obsahuje text vytvořený z různých řádků a odstavců, je-li to nutné. Obsahuje úplný popis instalovaného software. Účelem je pomoci uživateli v rozhodnutí, zda chce balíček instalovat nebo ne.

Můžete se zkusit zeptat se sám sebe: „A co překlad (translations)?“ Pro zlepšení čitelnosti spec souborů jsou překlad souhrnu (summary) a popisu (descriptions) jsou uloženy v samostatném souboru nazvaném <balíček>.po.

Tyto soubory jsou uloženy v poSPEC modulu v Cooker cvs. Při vytvoření nového balíčku je v tomto modulu základ po souboru je automaticky vytvořen pro budoucí překlady.

Tato metoda předpokládá, že veškerý text ve spec souboru je v angličtině. s vyjímkou balíčků určených pro konkrétní jazyk (např. ispell-de). V takovém případě je doporučeno mít text dvojjazyčný: Anglicky a v jazyce specifickém pro balíček. Budete používat pro tyto účely připravený tag: Summary(de): .. a %description -l de.

%prep 
%setup -q -a 1
%patch0 -p1 

Do této části je zapsán první script, který má program rpm provést. Jeho úlohou je:

• vytvořit hlavní podadresář programu (v adresáři BUILD)
• rozbalit původní zdroje do adresáře vytvořeného v předchozím kroku
• použít vybrané záplaty na zdrojové soubory.

Může být následován jakýmkoli příkazem který je zapotřebí pro přípravu zdroje ke kompilaci.

 %setup -q -a 1

Toto je odkaz na vestavěný script, který:

• přejde do adresářového stromu pro kompilaci
• rozbalí zdroj(e) (quietly, -q, potichu)
• změní vlastníka a práva u zdrojových souborů.

Defaultně rozbalí první zdroj; pro každý další zdrojový soubor musíte použít příslušné parametry. V našem příkladu - a 1 říká, že chceme extrahovat zdroj číslo 1.

Existují i další zajímavé přepínače, které můžeme použít společně s příkazem %setup:

• -c jméno - přepínač -c říká, že nejprve je vytvořen nejvyšší adresář „jméno“; pak příkazem cd přejde do tohoto adresáře a pak rozbalí SourceO . Je užitečný, jsou-li pro balíčky nevhodné (unbecomed) (význam?; DickGevers) tar.bz bez uvedeného nadřazeného adresáře.
• -D - nevymaže adresář před rozbalením. Může být užitečné, máte-li více než jedno setup makro. Mělo by být použito pro nastavení jiného makra než prvního (nikdy ne v případě jen jednoho).
• -T Tato volba mění standardní nastavení pro rozbalení zdroje (untarring) a vyžaduje -b 0 nebo -a 0 pro získání hlavního zdrojového souboru nekomprimovaného programem tar. Je zapotřebí pokud existuje druhý zdroj.
• -n jméno - je-li jméno rpm jiné než jméno zdroje, který je zapotřebí rozbalit, použijte tento vypínač. Například: Je-li jméno rpm sestaveno podle vzoru program-verze-revize a rozbalený zdroj má jméno program-verze-datum, nebude program rpm schopen přejít do správného adresáře program-verze, použijte přepínač -n program-verze-datum . Pak program rpm uvidí nový adresář, ve kterém může pokračovat v činnosti.

 %patch0 -p1 

Jde o makro zodpovědné za použití záplat na zdrojové soubory; jeho parametr -p<číslo> přesměruje program k záplatě.
Představme si, kdyby existovala další záplava deklarovaná pomocí Patch1: ..v sekci header by jste přidali další řádek: %patch1 -p1 . Přidání -b .vaše_přípona je také dobrý způsob, jak můžete nechat druhé zjistit, co vaše záplata dělá a kdo ji vytvořil. Například pokud vytvořil záplatu Fred, pak může napsat %patch -p1 -b .fred, pokud ale Barney, pak může zadat %patch -p1 -b .barney

 %build 

Tato část obsahuje scripty přimo zodpovědné za kompilace software. Sestává z příkazů vydaných po rozbalení ze zdrojového stromu.

 %configure 

Řádek používaný pro konfiguraci automaticky konfigurovaných zdrojů. %configure může nastavit ./configure s řadou rozšíření, jako např.

 export CFLAGS="$RPM_OPT_FLAGS" 

před konfigurací, a volby jako

 i586-mandrake-linux --prefix=/usr --datadir=/usr/share 

atp.

Někdy nejsou všechny volby konfiguračním scriptem podporovány. V takovém případě musíte zjistit příčinu a zajistit ./configure s vhodnými parametry. Zadejte cílovou platformu do volání configure, pokud je podporuje, pomocí %{targetplatform} ; specifikace architektury musí být zrušena v souborech spec; pro ix86 bude rozšířeno na i586-mandrake-linux, jak ukazuje výše uvedený příklad.

Všimněte si, že budete potřebovat balíček libtool aby bylo možné použít %configure na tvorbu balíčků sdílených knihoven.

Během tvorby a testování vašich balíčků by jste si měli ověřit, je-li cílový počítač architektury i586; zvláště pokud kompilujete pro vyšší verzi procesoru, standardní chování scriptu configure je zjistit si typ vašeho procesoru a optimalizovat kompilaci pro něj. Účelem parametru %configure je toto chování změnit.

 %make 

Jednoduché makro, které v podstatě zajistí kompilaci s vhodným parametrem pro víceprocesorové stroje -j<číslo> . Pro zdroje používající xmkmf by jsi měl nahradit make tímto příkazem:

 make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS" 

Ve většině případů (nikoli však ve všech) toto jednoduché nastavení make funguje.

 %install 

Tato sekce bude obsahovat script zodpovědný za simulovanou instalaci balíčku v rpm adresáři: $RPM_BUILD_ROOT. Bude obsahovat všechny nezbytné příkazy potřebné k tomu, aby software mohl fungovat na uživatelském počítači.

rm -rf $RPM_BUILD_ROOT

Toto je první z instalačních příkazů sekce %install; vyčistí případný předchozí instalační adresář.

%makeinstall

Tento řádek zajistí simulovanou instalaci software do adresáře pro autokonfiguraci zdroje. Toto makro je pro spouštění „make install“ vybaveno mnoha volbami pro simulaci adrsáře $RPM_BUILD_ROOT ap.

prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir}

atd.

V některých případech konfigurační script nemusí fungovat správně, a může být potřeba objevit v Makefiles další potřebné parametry pro správnou instalaci. Nejdříve asi využijete DESTDIR=$RPM_BUILD_ROOT.

Pro úsporu místa na disku a zkrácení času přenosu souboru, Mandriva používá bzip2 pro komprimaci man- a info- stránek. Tuto vlastnost ovládá přímo rpm program Mandrivy. V té souvislosti je potřeba zmínit, že některé spec soubory starších balíčků obsahovaly některé řádky jako find $RPM_BUILD_ROOT%{_mandir} -type f -exec bzip2 -9f {} \;. Totéž funkci pro starší soubory zajiští řádek strip $RPM_BUILD_ROOT%{_bindir}/* ||. Řádek musí být smazán. To vše se musí připravit, aby se mohly zabalit připravené soubory.

%clean

Tato sekce je určena k pročištění adresářového stromu $RPM_BUILD_ROOT.

rm -rf $RPM_BUILD_ROOT

Tím je práce na novém balíčku dovršena.

%files

Tato část se sestává ze seznamu souborů, které budou vybírány ze simulovaného adresářového stromu připravovaného do balíčku. Projděte si krásný návod (fine manual) pro seznámení se s dalšími volbami, které nejsou použity v tomto příkladu.

Seznam souborů musí být zapsán ručně to souboru spec. Má být tvořen seznamem všech souborů vytvořených v adresářové struktuře. Aby se to mohlo vytvořit, napište

rpmbuild -bi nazev_balicku.spec

. Parametr způsobí, že se příprava balíčku zastaví, jakmile rpm dokončí simulovanou instalaci. Pak můžete adresáře projít (připomínám, že jde o adresář ~/rpm/tmp/ ) a rozhodnout se, které soubory chcete v balíčku mít. Zpravidla to budou všechny.

Poznámka: Nepoužívejte pro tvorbu seznamu find , ale tvořte ho po jednotlivých souborech (můžete tak odhalit chyby v nových verzích). Jedinou vyjímkou jsou locales, v nichž by se měl použít find_lang %{name} v sekci %install a nahraďte nadpis sekce %files za %files -f %{name}.lang (viz Dodatek B).

Poznámka k adresářové struktuře: Soubory instalované z vašeho balíčku by měly respektovat doporučení FHS, viz pathname.com/fhs

%defattr(0755,root,root)

Tenhle tag definuje vlastnosti nastavované u každého souboru, který bude nakopírován do uživatelova systému. Čtveřice argumentů znamená:

• -: všechny atributy pro standardní soubory zůstanou nezměněny
• root: vlastník souboru je root
• root: skupina vlastníka je root
• 0755: soubor práv nastavených ve všech adresářích vlastněných timto balíčkem; v tomto případě je 0755 (rwxr-xr-x)

%doc README NEWS COPYING AUTHORS

Speciální tag %doc určije soubory, které se stanou součástí dokumentace balíčku. Zde vyjmenované soubory budou uloženy v /usr/share/doc/gif2png-2.0.1/. Adresář pro ně bude také automaticky vytvořen. Soubory určené v tagu %doc jsou uloženy v relativních umístěních k vašemu rozbalenému zdrojovému adresáři BUILD.

%{_mandir}/man1/gif2png.1*
%{_mandir}/man1/web2png.1*

Také soubory man nebo info do tohoto seznamu je doporuceno zapisovat jednotlivě.

Možná se divíte, proč se používá název gif2png.1* místo gif2png.1.bz2. Důvodem je uchovat si možnost záměny s dalšími systémy, které by mohly využívat gzip komprimaci namísto bzip využívaného v Mandriva Linuxu. Pokud najdete odkaz na bz2 komprimaci v souborech spec, změnu zajistí značka pro hromadný výběr souborů. Zpravidla můžete dokonce použít %{_mandir}/man1/* , což převezme všechny soubory, které může find najít.

%{_bindir}/gif2png
%{_bindir}/web2png

Jak můžete vidět, máte k dispozici makro pro každý druh činnosti, kterou potřebujete. Zde jsou některé z nejužitečnějších (podívejte se do /usr/lib/rpm/macros pro informace o dalších): %{_prefix} , %{_bindir} , %{_sbindir} , %{_datadir} , %{_libdir} , %{_sysconfdir} , %{_mandir} , %{_infodir} . Pro hry můžete použít %{_gamesbindir} a %{_gamesdatadir} .

 %changelog

Tato část slouží k zaznamenání různých změn provedených v balíčku. Každé nové vydání balíčku musí souhlasit s odstavcemv této části stejně tak, jako povýšení čísla vydání (release) (pokud nejde o změnu čísla verze (version number). Odstavce musí mít níže uvedené strukturování.

* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-1mdk 

První řádek odstavce začíná hvězdičkou (*) a údaje jsou odděleny mezerníkem:

• tři pozice pro den v týdnu,
• tři pro měsíc,
• dvě číslice pro den v měsíci,
• čtyři číslice pro rok,
• křestní jméno a příjmení osoby, která balíček připravila, oddělené mezerníkem,
• v lomených závorkách (<>) emailovou adresu,
• následuje číslo verze a vydání současné úpravy

 - Upgraded to 2.0.1

Následuje řádek o modifikacích balíčku, začínajících “-“. Tady je příklad:

- spec file stolen from korganizer. 
- last snapshot before release 
- Mandriva adaptations. 
- Fix bug in /etc/zsh use USERNAME instead of USER. 
- Remove petit bouchon which annoys other players. 
- Improve /etc/z* to source the /etc/profile.d/ files. 
- fix typo in examples directory name 
- fixed QT libs version requirements 
- add patch to handle Earl Grey tea 

V dokončeném rpm balíčku budou uchovány jen záznamy o změnách mladší jednoho roku. Pokud toto chování chcete změnit, můžete upravit hodnotu %_changelog_truncate.

Náš soubor spec je úplně dokončen. Hluboce se nadechněte, sedněte si a zadejte: rpmbuild -ba mypackage.spec. Můžete také přidat parametr –clean, který zajistí vyčištění adresáře BUILD po dokončení vytváření balíčku. tuto volbu oceníte, máte-li málo místa na disku.

Nyní máte dvě možnosti, podle toho, co se zobrazí na posledním řádku výpisu probíhajícího procesu tvorby rpm:.

1. 0.01% pravděpodobnost: +exit 0
2. 99.9% pravděpodobnost: jiné případy.

Nastala první možnost? Gratulujeme, test jste zvládli, již nejste neználek.

Štěstí, čas a prohlížení voleb dostupných v procesu tvorby rpm ( man rpmrebuild ) pro ladění vaší práce, inspirace z ostatních spec souborů atd.

Přímá cesta ve tvorbě balíčků je tato:

rpmbuild -bs --rmspec --rmsource

(za účelem odstranění pozůstatků z předešlé kompilace) a nakonec

rpmbuild --rebuild

.

Po potvrzení příkazu ke kompilaci balíčku můžete vidět hlášení jako např.

 foo-devel i necessary for foo2

(=balíček foo-devel je nutný pro balíček foo2).

To znamená, že rpm pro dokončení kompilace potřebuje informace z jiných balíčků používaných pro vývoj (zpravidla je soubor pojmenován foo.h). Pokud je nemáte, kompilace se zastaví, nebo příslušná vlastnost bude ve vašem balíčku chybět.

Chcete-li kompilovat mnoho oficiálních balíčků (pro Mandrivu), musíte mít předinstalováno mnoho „devel“ balíčků. Pokud není deklarovaný ve vašem souboru spec a je přitom nezbytný, balíček bude vytvořen „on the cluster“. Bude funkční, ale nepřítomnost této informace zabrání kompilaci na počítačích, kde chybí příslušný devel balíček. Tvorba, debugging a aktualizace bude daleko obtížnější.

Podívejte se na domovskou stránku programu, kde obvykle naleznete informace o potřebných součásech.

Pro omezení chyb při kompilaci typu „nesplněných závislostí“ je potřeba mít nainstalovány základní devel balíčky:

• glibc-devel
• libncurses5-devel
• libstdc++6-devel

Poté již stačí nainstalovat jen devel balíčky vyžadované príkazem rpm build pro konkrétní kompilovaný balíček.

Po spuštění kompilace pozorně sledujte zprávy jako „checking for …“

Jestliže vidíte něco jako checking for foo… foo.h not found, znamená to, že potřebný hlavičkový soubor nebyl v systému nalezen. Hledejte devel balíček, který obsahuje „foo.h“, ale buďte obezřetní: můžete najít více než jeden balíček obsahující komponentu se stejným názvem. Vyberte balíček „more obvious“ - ve smyslu více příbuzný s kompilovaným balíčkem. Nevybírejte balíček „network“, pokud kompilujete zvukovou aplikaci (například).

Po nalezení a jej nainstalujte do systému a nezapomeňte přidat jeho jméno do sekce BuildRequires v souboru SPEC.

Chybějící hlavička může být také nalezena během kompilace sama. Jestliže se kompilace zastaví, zkontrolujte další chybějící „foo.h“ a použijte tentýž postup.

Měli by jste také zkontrolovat stránky bugzily pro případné další informace o tomto námětu.

Prvním krokem je:

• jsou rpms vytvořené v příslušných adresářích se správnými jmény? (v ~/rpm/SRPMS a ~/rpm/RPMS/i586/ )
• jsou informace získené příkazem rpm -qlivp -changelog muj_balicek.(src)rpm správné?

V dalším kroku musíte použít rpmlint, který provede některé testy balíčku. Napište

rpmlint muj_balicek.<archtype>.rpm

a získáte zprávu o testovaném balíčku. Pro zvýšení preciznosti testu použijte přepínač -i. Měli by jste kontrolovat jak rpm, tak i src.rpm. Další informace o chybách můžete najít na stránkách Packaging Problems

Na libovolný počítač - ale raději na jiný, než na kterém byla prováděna kompilace - proveďte aktualizaci nebo instalaci a pak zkontrolujte:

• Jsou všechny očekávané soubory vytvořené v předpokládaných místech, s předpokládanými právy a vlastníky?
• jsou všechny instalační modifikace (pokud existují) funkční?
• Jsou všechny binárky spustitelné a je dokumentace dostupná konečným uživatelům?

Perfikcionisté by měli zkoušet různé instalace a odinstalace ke kontrole, jsou-li všechny vlastnosti implementovány korektně, například bez požadovaných balíčků.

Jsou-li všechny testy úspěšné, jste již skoro hotovi a můžete přikročit k poslednímu kroku: submitting balíčku

Zdá se, že jste četli toto HowTo, je to dobrý začátek. Pokud jste nenašli odpověď na svoji otázku, měli by jst vyzkoušet další zdroje informací v uvedeném pořadí:

1. oficiální RPM-HOWTO (je instalováno spolu s programem rpm na váš systém)
2. kniha od Red Hatu Maximum RPM
3. odeslat dotaz na některou ze seznamu adresu uvedených na začátku tohoto článku.

Napište oddělení Mandriva Quality Assurance, adresa qa@mandriva.com.

Cítíte-li, že informace, které jste získali, mohou být užitečné pro ostatní čtenáře tohoto dokumenut, nezdráhejte se podat návrh na změnu či doplnění správci tohoto dokumentu.

Balíček rpm je ve skutečnosti o něco složitější, než jednoduchý archív obsahující soubory rozbalované do příslušných adresářů na systému uživatele.

Systém nabízí programátorovi zásadní vlastnost: před a poinstalační scripty. Umožňuje to napsat kód, který se provede na hostitelském počítači během instalace nebo odinstalování balíčku.

Tyto scripty jsou vykonány jakýmkoli platným příkazem shellu. Čtyři z nich jsou základní:

Existují určité námitky ohledně těchto scriptů, které je potřeba vzít do úvahy. Za prvé, každý musí vejít do bufferu 8192, za druhé neměli by být interaktivní. Jakmile bude vyžadován vstup uživatele, zkazí to neinteraktivní instalační proceduru.

• %pre - script je vykonán jen před instalováním balíčku do systému.
• %post - script vykonán jen po instalaci balíčku do systému
• %preun - script vykonán jen před odinstalací balíčku
• %postun - script vykonán jen po odinstalací balíčku

Možnosti takových scriptů mohou být velmi rozsáhlé, a musí být navrženy s velkou pozorností, aby nepoškodily hostitelský systém. Uvědomujte si, že scripty poběží s právy roota… Souvisí s úlohou správce systému, který musí nové programy do systému instalovat. Například:

• přidat úlohu pro cron k periodickému spouštění programu
• spustit chkconfig pro spuštění služby během startu systému
• …

Fakt, že balíček může být aktualizován, a ne jen jednoduše instalován nebo odstraněn, to komplikuje… Problémem je, že script %postun z aktualizačního balíčku je spouštěn až po scriptu %post starší verze. Tím je všechen výsledek dosažený scriptem %post ztracen…

Proto je často užitečné zajistit, které akce se mají provést jen během instalace, avšak ne během aktualizace. Podobně také které se mají provést jen během odinstalování a ne během aktualizace. RPM zajišťuje tyto potřeby tím, že přidal standardní argument ke scriptům %pre, %prein, %post a %postun . Tento argument signalizuje počet instancí tohoto rpm, který bude instalován na počítač po dokončení aktuálního scriptu. Například je-li nový balíček instalován, pak bude „1“ předána scriptu %pre i %post. Pokud probíhá aktualizace, bude předán parametr 2 scriptům %pre, %post z nového RPM, 1 pak scriptům %preun a %postun starého balíčku.

Parametr \ Script 	%pre 	%post 	%preun 	%postun 
první instalace 		1 	1 	N/C 	N/C 
aktualizace  		2	2 	1 	1 
odinstalace 		N/C 	N/C 	0 	0

To umožní programátorovi zajistit různé chování scriptů v závislosti na operaci: instalaci nebo aktualizaci.

• instalační scripty (%post, %pre ) zkontrolují, zda parametr $1 = „1“, pak jde o instalaci, pokud ne, jde o aktualizaci.
• odinstalační scripty (%postun, %preun ) zkontrolují, zda parametr $1 = „0“, pokud ano, jde o normální odinstalaci; pokud ne, jde o aktualizaci nebo přeinstalaci stejné verze s parametrem –force.

Pro otestování tohoto argumentu se používá následující „if“:

%postun
if [ $1 = 0 ]; then
    // Do stuff specific to uninstalls
fi
if [ $1 = 1 ]; then
    // Do stuff specific to upgrades
fi 

Jediný test stačí k tomu, aby vyvolal podle okolností správné akce.

Při spuštění MandrivaLinux2009.0, rpm filetriggers je používáno k odstranění opakujících se úloh jako je

%post -p /sbin/ldconfig

nebo

%update_menus

.

Při kompilaci RPM pro Mandriva Linux máte k dispozici více maker, k usnadnění vytvoření souboru spec.

• Manipulace s info stránkami. Příklad je nejlepší učitel:

%post
%__install_info %{name}.info

%preun
%__install_info %{name}.info

• Systém menu. Počínaje verzí Mandriva Linux 2007.0, je defaultně používán Mandriva XDG Menu systém, nahrazující starší Debian Menu system.

%post
%{update_menus}

%postun
%{clean_menus}

• Snadné zacházení s lokalizacem. Nejlepším způsobem není ručně vkládat .mo soubory, které jsou obvykle uloženy v /usr/share, ale použít zvláštní makro v sekci %install, které pro to vytvoří speciální soubor:

%find_lang %{name}

Pak použijete soubor v seznamu:

%files -f %{name}.lang

• Tvorba makra. Vytvořená makra %configure a %makeinstall jsou nyní docela velké. Přesně určí prefix, ale také každý běžný adresář (jako např. bindir, datadir atd.); pracují bezchybně s balíčky malé a střední velikosti, u ostatních je zapotřebí určité pozornosti. Makro %make vykoná příkaz make s vhodným parametrem -j <číslo> pro využití výkonu počítače s více procesory. Pokud potřebujete spustit ručně script ./configure, NIKDY nemá mít pevně uvedenou architekturu; k tomu slouží makro %{targetplatform} (nebo přímo %{tartetcpu}, bude-li to nutné).
• Kompilace serverových aplikací. Pro kompilace bezpečnějších serverů používáme zvláštní makro, %serverbuild, které používáme před vlastní kompilací. To umožní bezpečné nastavení přepínačů. Sekce %build bute vypadat asi takto:

%build
%serverbuild
%configure
%make

• Makro initscript. Pokud instalujete balíčky, které poskytují vlastní initscripty (soubory v adresáři /etc/init.d ), potřebují být přidány pomocí volání, které vypadá jako chkconfig –add … ale ne jako v případě aktualizací, ale potřebuje zajistit restart služby již běžící; při odinstalaci musí jednat odlišně (opačně). Máme makro, které to zajistí bez chyby:

%post
%_post_service <initscript-name>

%preun
%_preun_service <initscript-name>

• Manipulace s ghostfiles. Většina her a některé jiné balíčky používají proměnlivý soubor, který může být i nepřítomen. V takových případech jsou užitečné ghostfiles (soubor duch, neviditelný soubor). Tady je příklad:

%install

(...)

mkdir -p $RPM_BUILD_ROOT/var/lib/games
touch $RPM_BUILD_ROOT/var/lib/games/methanescores

%post
%create_ghostfile /var/lib/games/powermanga.hi root games 664

(...)

%files
%attr(664, root, games) %ghost /var/lib/games/powermanga.hi

Makro %create_ghostfile to expanduje takto:

if [ ! -f /var/lib/games/powermanga.hi ]; then 
  touch /var/lib/games/powermanga.hi
  chown root.games /var/lib/games/powermanga.hi
  chmod 664 /var/lib/games/powermanga.hi
fi 

• Mapování MIME asociací v souboru .desktop: systém menu XDG umožňuje nastavení asociací mezi aplikací a MIME typy v souboru .desktop. Spusťte utilitu update-desktop-database , je-li takový soubor .desktop v systému instalován nebo odinstalováván, použijte makro, které je uvedeno v následujícím příkladu:

%post
%update_desktop_database

%postun
%clean_desktop_database

• Databáze MIME typů Freedesktop.org: Databáze používá seznam všech dostupných MIME typů s magickými čísly nebo vzorovými příponami, které měly být aktualizovány použitím makra podle následujícího příkladu:

%post
%update_mime_database

%postun
%clean_mime_database

• Vyrovnávací paměť pro ikony (Icon cache): Pokud balíčky obsahující ikony uložené v /usr/share/icons/hicolor (nebo v dalších adresářích obsahujících používané ikony, jako je /usr/share/icons/gnome/ nebo /usr/share/icons/crystalsvg/ ) musí být aktualizovaná icon cache, jak je uvedeno níže (ikon uložených v /usr/share/icons, /usr/share/icons/mini nebo /usr/share/icons/large se tento požadavek netýká):

...
%file
...
%{_iconsdir}/hicolor/*
%{_iconsdir}/crystalsvg/*
....

%post
%update_icon_cache hicolor
%update_icon_cache crystalsvg

%postun
%update_icon_cache hicolor
%update_icon_cache crystalsvg

• Schéma registrace GConf: Schémata GConf v prostředí GNOME musí být instalovaná/odinstalovaná použitím tohoto makra:

...
# each schema key here corresponds to a file named /etc/gconf/schemas/<key>.schemas
%define schemas apps_gnome_settings_daemon_default_editordesktop_gnome_font_rendering desktop_gnome_peripherals_keyboard_xkb fontilus themus

%post
%post_install_gconf_schemas %{schemas}

%preun
%preun_uninstall_gconf_schemas %{schemas}

• Aktualizace databáze Scrollkeeper: Databáze scrollkeeper (používaná pro indexy docbook dokumentace) by měla být aktualizována při instalaci souboru .omf takto:

...
%post
%update_scrollkeeper

%postun
%clean_scrollkeeper

někdy je zapotřebí zobrazit upozornění pro uživatele, jestliže například probíhá instalace či aktualizace zvláštní verze balíčku. rpmdrake-2.1.3-11mkd poskytuje následující podporu: vyhledá v rpms v textové souborech s názvy README.install.urpmi nebo README.update.urpmi nebo README.urpmi a zobrazí je.

README.install.urpmi je zobrazený při instalaci balíčků; README.update.urpmi jen v případě aktualizací balíčku; a README.urpmi v obou případech.

Skupiny v Mandriva Linuxu. Seznam skupin naleznete v dokumentu RPM Groups

Schválené licence používané v Mandriva Linuxu najdete v dokumentu Mandriva Licences.

checkinstall je již dlouhou dobu nefunkčním. Přesto z historického hlediska jistě zajímavým nástrojem na tvorbu RPM.

Velmi snadná cesta ke kompilaci balíčků rpm pro osobní použití je instalovat balíček checkinstall. Kompilace ze zdrojových kódů (obvykle ./configure && make && sudo make install) je pozměněna tak, že příkaz make install je nahrazen příkazem checkinstall. Tím se velmi zjednoduší kompilace rpm. Výhoda je v tom, že nemusíte obcházet správce balíčků, kompilujete-li programy ze zdrojových souborů. (Nepochybně lepší způsob je vytvářet rpm „řádně“, jak je popsáno výše, zejména chcete-li je distribuovat ostatním.)

• Ark linux howto
• IBM article on rpm building
• A redhat magazine article on rpm building
• Pdf tutorial on rpm building made by GuruLabs
• Red Hat RPM Guide