V tomto dokumentu se předpokládá, že se čtenář dokáže 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 Mageia, buď z předchozího zdrojového rpm nebo ze zdrojového souboru tar.

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: Mageia, Mandriva Linux, Suse atd.; rpm je již na těchto systémech nainstalován.

Můžete získat vanilla rpm distribuci od Red Hatu: ftp://ftp.rpm.org/pub/rpm/dist

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

Tvorba balíčků pro Cauldron (tedy vývojovou verzi Mageie) je vždy náchylná k malým záplatám a vylepšením používaného programu rpm. Měli byste nainstalovat následující balíčky:

• 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 (v 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.

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

• ~/rpm/BUILD: adresáře vytváření
• ~/rpm/BUILDROOT: adresář, kde instalace budou simulovány
• ~/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
• ~/rpm/RPMS/x86_64: adresář pro uložení balíčků pro procesory AMD64, Core 2 duo a pozdější
• ~/rpm/RPMS/noarch: totéž pro noarch balíčky (bez závislosti na procesoru)
• ~/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

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

# Pokud chcete, aby vaše balíčky byly podepsány GPG automaticky, přidejte tyto tři řádky
# nahrazením 'Mageia' vaším GPG názvem. Můžete také použít rpm --resign
# podepsat balíčky později.
%_signature             gpg
# _gpg_name obsahuje jméno zadané při vytváření GPG klíče
%_gpg_name              Mageia
%_gpg_path              ~/.gnupg

# Přidejte vaše jméno a e-mail do %packager uvedené níže. Možná také chcete
# nahradit vendor sebou.
%packager               John Doe  <foo@mail.invalid> 
%distribution           Mageia 
%vendor                 Mageia 
# Pokud chcete, aby vaše balíky měli svůj vlastní distsuffix místo mga, přidejte jej
# zde tak jako toto
#%distsuffix             foo

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

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

Nejnovější rpm soubory z repozitáře Cauldron jsou dostupné na mnoha zrcadlech, jejichž seznam je k dispozici v Cauldron Mirrors - i586, Cauldron Mirrors - x86_64. Tam najdete:

• v podadresáři SRPMS zdrojový rpms (core, nonfree, tainted) a dále cpu architekturu (např. i586, x86_64, …)
• media/core pro binární rpms repozitáře core
• media/nonfree pro binární rpms repozitáře nonfree
• media/tainted pro binární rpms repozitáře tainted

Když najdete zdrojový rpm, který chcete upravit pro Mageiu, 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@valstar ~/rpm]$ rpm -i /cauldron/SRPMS/core/ktron-4.5.95-1.mga1.src.rpm 
[camille@valstar ~/rpm]$ ls -R * 
SRPMS:
SPECS:
ktron.spec
SOURCES:
ktron-4.5.95.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-4.5.95.tar.bz2 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í, abyste lépe rozuměli, jak je balíček sestaven a kompilován. Magický příkaz pro sestavení balíčku je rpmbuild s volbou buildall:

[camille@valstar ~/rpm]$ cd ~/rpm/SPECS
[camille@valstar ~/rpm]$ rpmbuild -ba ktron.spec
[camille@valstar ~/rpm]$ ls -l ~/rpm/RPMS/i586/ktron-4.5.95-1.mga1.i586.rpm
[camille@valstar ~/rpm]$ ls -l ~/rpm/SRPMS/ktron-4.5.95-1.mga1.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žiji 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 knihovná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 Mageii je uložen v SVN 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 kořeni <svn/packages/cauldron>. Jsou přístupné na stránkách http://svn.mageia.org .

Pro další detailní informace o přístupu do SVN systému nahlédněte na stránku Mageia SVN FAQ.

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

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 a ve kterém úložišti: core (bez licence), nonfree (non-free licence) nebo tainted (záležitostmi v oblasti patentů uvnitř). Nelze přijmout uzavřený (non-open) software. 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 Mageia 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 nebo lepší kompresní algoritmus tar.xz. Vyhýbejte se komprimaci záplat v textových formátech (vytvořené např. programem diff a podobnými) a dalších 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).

  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 výjimky 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 vzniklé 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 Mageii.

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ů a patchů můžete vidět zde

Name:           gif2png
Version:        2.0.1
Release:        %mkrel 1
Summary:        Tools for converting websites from using GIFs to using PNGs 
Source0:        http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 
Source1:        %{name}-%{version}-mga-addon.tar.bz2 
Patch0:         gif2png-2.0.1-bugfix.patch
URL:            http://www.tuxedo.org/~esr/gif2png/ 

Group:          Applications/Multimedia 
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 %{buildroot}
%makeinstall   

%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 2010 Camille Begnis <camille@mageia.org> 2.0.1-1mga1
- Upgraded to 2.0.1 

* Mon Oct 25 2011 Camille Begnis <camille@mageia.org> 2.0.0-1mga1
- Specfile adaptations for Mageia
- 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, …)

Name:           gif2png

Jméno balíčku, které bude použito v databázi balíčků na počítači uživatele. Z osvědčených postupů by jméno mělo být malými písmeny. Všimněte si, že %{name} je odkaz na předchozí definici.

Version:        2.0.1
Release:        %mkrel 1

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 (např. gif2png-2.0.1-1.mga1.i586.rpm pro 32 bit. nebo gif2png-2.0.1-1.mga1.x86_64.rpm pro 64 bit. architekturu z našeho příkladu)
• zdrojový balíček je pojmenován následovně: jméno-verze-vydání-src.rpm (např. gif2png-2.0.1-1.mga1.src.rpm v našem 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 nezáplatovaného zdroje. Jde o číslo verze z jména v původním komprimovaném souboru: jméno-verze.tar.gz.

Vydání (release) je číslo následované písmeny mga1 (znamenající „Mageia 1“; toto je naprosto nezbytné) je přírůstkové čí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é ve zdroji, úprava souboru spec, přidání ikon atp.

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

Tento řádek obsahuje jednořádkový popis balíčku. Počet písmen by mělo být max. 79, bez tečky na konci, první znak velké písmeno a bez mezery na začátku textu.

 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.

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

Všimněte si, že % {name} a % {version} jsou odkazy na předchozí tagy.

Patch0:         gif2png-2.0.1-bugfix.patch

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

• 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.
• byli jste upozorněni na patch pro verzi vašeho softwaru někde na síti a stáhli jste si ho; nebo jej vybrali z upstreamu (ze SVN, GIT, … atd.).

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í domovskou 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.

Kompletní struktura skupin, kterou lze použít, se liší od Red Hatu, lze ji najít na stránkách RPM Groups (en). 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 Mageia instalátorem 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:

• vytváříte-li balíčky rpm a nemáte oprávnění roota, nemůžete instalovat sadu programů v obvyklých adresářích.
• 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 GPLv2. Kompletní seznam schválených licencí najdete na stránkách Mageia Licensing Policy, zejména část Standard license names pro úplný seznam platných licencí a pravidel.

 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 softwaru. Úč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ů je překlad souhrnu (summary) a popisu (descriptions) uložen v samostatném souboru nazvaném <balíček>.po.

%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 (v našem příkladě Source0); pro každý další zdrojový soubor (archivy) musíte použít příslušné parametry. V našem příkladu -a 1 říká, že také chceme extrahovat zdroj číslo 1 (v našem příkladě Source1).

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

%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ě. Podíváte-li se do patch souboru, uvidíte, že některé cesty jsou definovány:

--- cairo-1.7.6-orig/src/cairo-ft-font.c	2008-09-29 21:43:13.000000000 +0100
 +++ cairo-1.7.6/src/cairo-ft-font.c	2008-09-29 21:52:19.000000000 +0100
 @@ -1705,7 +1705,9 @@
  	options->base.subpixel_order = other->base.subpixel_order;
      }
  
 -    if (options->base.hint_style == CAIRO_HINT_STYLE_DEFAULT)
 +    options->base.hint_style = CAIRO_HINT_STYLE_DEFAULT;
 +
 +    if (other->base.hint_style != CAIRO_HINT_STYLE_DEFAULT)
  	options->base.hint_style = other->base.hint_style;
  
      if (other->base.hint_style == CAIRO_HINT_STYLE_NONE)

V tomto případě -p1 znamená, že oprava by měla ignorovat cairo-1.7.6/, -p2 by znamenalo, že také ignorovat src/ a tak dále …

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římo 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-mageia-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-mageia, jak ukazuje výše uvedený příklad.

Pro přehled o tom, co vlastně dělá rpm při vydávání %configure2_5x, můžete spustit rpm - eval % configure2_5x v terminálu.

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 jste měli 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: %{buildroot} nebo ekvivalentní $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 %{buildroot}

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, aby se instaloval software v %{buildroot}, např. prefix=$RPM_BUILD_ROOT%{_prefix} bindir=$RPM_BUILD_ROOT%{_bindir} nebo jednodušeji DESTDIR=%{buildroot}. Znovu se podívejte, jak toto makro je rozšířeno, použijte rpm - eval% makeinstall_std.

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. Jedním z nejčastějších z nich je, že někdy budete muset použít make DESTDIR=$RPM_BUILD_ROOT install nebo jen %makeinstall_std. Seznam běžně používaných proměnných pro Makefile můžete najít v Gnu|Coding Standard page.

Pro úsporu místa na disku a zkrácení času přenosu souboru, Mageia používá xy pro komprimaci man- a info- stránek. Tuto vlastnost ovládá přímo rpm program Mageii.

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.

Tato část je zastaralá a toto bude automaticky provedeno samotném RPM. To by mělo být odstraněno ze SPEC souborů a již nepoužívat.

%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 muj_balicek.spec. Parametr způsobí, že se příprava balíčku zastaví, jakmile rpm dokončí simulovanou instalaci. Pak můžete adresáře projít ~/rpm/BUILDROOT/gif2png (v našem případě) a rozhodnout se, které soubory chcete v balíčku mít. Zpravidla to budou všechny.

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(-,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á:

%doc README NEWS COPYING AUTHORS

Speciální tag %doc určuje 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 doporučeno zapisovat jednotlivě.

Možná se divíte, proč se používá název gif2png.1* místo gif2png.1.xz. Důvodem je uchovat si možnost záměny s dalšími systémy, které by mohly využívat gzip komprimaci namísto xz využívaného v Mageii. Pokud najdete odkaz na xz komprimaci v souborech spec, změňte zástupný znak (*). 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 celý seznam): %{_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 odstavcem v 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 2010 Camille Begnis <camille@mageia.org> 2.0.1-1mga1
• 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
  * Mageia 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:.

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

Nastala druhá 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 is 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 Mageiu), 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 v clusteru. 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 nebo README/INSTALL soubory ve zdrojovém tarball souboru, kde obvykle naleznete informace o potřebných součástech.

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é příkazem rpmbuild pro konkrétní kompilovaný balíček.

Po spuštění kompilace pozorně sledujte zprávy jako checking for … ve výstupu .configure

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í 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 jsou:

• 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ískané příkazem rpm -qlivp --changelog mypackage.(src.)rpm správné?

V dalším kroku musíte použít rpmlint, který provede některé testy balíčku. rpmlint je nástroj pro kontrolu běžných chyb v RPM balíčcích. Je nastaven pro kontrolu Mageia balíčků (v závislosti na různých politik RPM balení v Mageii), ale měly by tak fungovat se všemi balíčky RPM. Používají také SUSE a RedHat.

Napište

rpmlint muj_balicek.<$ARCH>.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. Můžete nakonfigurovat rpmlint se souborem ~/.rpmlintrc nebo /etc/rpmlintrc. Měli byste nastavit alespoň následující:

from Config import *
setOption("Packager","login@email.org")
# default value
# setOption('Packager', 'Mageia Team <http://www.mageia.org>|@mageia.org')
addFilter("E: .* no-signature")
addFilter("W: .* invalid-packager")
addFilter("E: .* no-packager-tag")
addFilter("E: .*-debug .*")
addFilter("W: .*-debug .*")   
# not very clean, but easier to maintain
release_tag = os.popen("rpm %%--%%eval '%mkrel 1'").readlines()[0][1:-1]
setOption('ReleaseExtension', release_tag)

Pokud máte v úmyslu vytvořit rpm vhodné pro zařazení úložiště Mageie, měli byste také zajistit, že balíček rpmlint-mageia-policy je nainstalován, neboť obsahuje různé konfigurace a politiky používané baliči Mageie.

rpmlint zkontroluje spoustu věcí, jako: tagy, binárky, konfigurační soubory, umístění, oprávnění, vlastnictví, FHS dodržování, zdroje, menu, skripty, spec soubor obsahu … Pro více informací se podívejte na /usr/share/rpmlint/config.d/mageia.error.list.

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?

Perfekcionisté 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: předložení balíčku

No, zdá se, že jste četli toto HowTo, což je dobrý začátek. Pokud jste nenašli svou odpověď tady, měli byste se pokusit v daném pořadí:

• Oficiální RPM-HOWTO (instalován společně s rpm programem na vašem systému).
• Kniha od Red Hat „Maximum RPM“, která je dostupná na http://www.redhat.com/docs/books/max-rpm/max-rpm-html
• Poslat dotaz mageia-dev, které jste si předplatili před dlouhou dobou na začátku čtení těchto HOWTO stránky.

Napište oddělení Mageia Quality Assurance.

Cítíte-li, že informace, které jste získali, mohou být užitečné pro ostatní čtenáře tohoto dokumentu, 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.

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.

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

• Snadné zacházení s lokalizacemi. 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 bude 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 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

Můžete kdykoli zkontrolovat obsah daného makra pomocí rpm --eval:

$ rpm --eval %update_icon_cache
if [ -x /usr/bin/gtk-update-icon-cache ]; then 
/usr/bin/gtk-update-icon-cache --force --quiet /usr/share/icons/%{1} || true; fi

Můžete také zobrazit seznam všech hodnot a maker používané rpm od maker a rpmrc souborů: rpm - showrc

Níže uvedené informace jsou ponechané ze staršího návodu

• 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. Následující formáty jmen souborů může být použito:

• README.install.urpmi - zobrazí, když je balíček původně nainstalován
• README.version.upgrade.urpmi a README.version.update.urpmi - zobrazí, když je balíček aktualizován na verzi version nebo vyšší, od verze, která je nižší než version(version by měl být buď balíček version, epoch:version, version-release, nebo epoch:version-release, kratší tím lépe).

Také jsou podporovány README.urpmi (zobrazuje ve všech případech) a README.upgrade.urpmi / README.update.urpmi (vždy zobrazena při upgradu). Ty by neměly být používány, protože způsobují zprávu ukazující v každé následné aktualizace, a to i v případě, že uživatel již viděl zprávu mnohokrát.

HOW TO DO (příklad s README.install.urpmi):

• umístit README.install.urpmi ve zdrojích / adresáře
• přidat do spec jako SourceX: README.install.urpmi (nahradit X s odpovídajícím číslem)
• v %install section: install -m644 %{SOURCEX} README.install.urpmi (všimněte si zde absenci %buildroot)
• v %files sekci, přidejte README.install.urpmi v %doc makru nebo přidejte %doc makro, pokud tam žádný není

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.)

• Milux - Linuxový zápisník - Správa balíků softwaru - RedHat Package Manager

• 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

Originál překladu - https://wiki.mageia.org/en/Packagers_RPM_tutorial. Zde naleznete zkrácenou verzi tohoto článku