Správa balíčků s RPM (2)

Binární balíčky jsou pohodlné, rychle použitelné a často dokonce menší než zdrojové kódy (to platí hlavně pro knihovny, které se u RPM kompilují do dvou binárních balíčků, kdy jeden je určen pro běh a druhý pro kompilace aplikací – ten první mnohdy postačuje). Jenže občas narazíte na problém, že autor použil při kompilaci jinou verzi knihovny, než máte zrovna vy, nebo třeba nezahrnul do binární podoby nějakou vlastnost, kterou považoval za okrajovou a bez které vy nemůžete být (třeba podporu češtiny :). V takovém případě vám nezbude nic jiného, než sáhnout po zdrojových kódech. Jak jsem se již zmínil, matlání RPM a obyčejných zdrojáků může docela zkomplikovat život, ale nic není ztraceno. I zdrojové kódy mohou být totiž v rpm balíčku. A někdy není potřeba ani to.

Pokud máte k dispozici zdrojové kódy v rpm (takový balíček se jmenuje stejně, jako binární, ale místo architektury je v koncovce slovíčko src – např. balicek-1.0–2.src.rpm), máte dvě základní možnosti, jak s nimi naložit. Pakliže pouze potřebujete vytvořit binární balíček bez dodatečných nastavování, například když vám jde jenom o to, mít binární balíček, který reflektuje aktuální verze vašich knihoven a podobně, použijte parametr –rebuild. Ten za vás udělá vše, co si budeme popisovat dále a navíc po sobě zase pěkně uklidí. Pozor, z jednoho zdrojového balíčku může vzniknout více binárních a hlavně se nikdy neumisťují do aktuálního adresáře. Výsledek svého snažení musíte hledat v adresáři /usr/src/<jmé­no distribuce>/RPMS/<ar­chitektura>
Například pokud máte Red Hat Linux na platformě Intel, bude z největší pravděpodobností binární balíček umístěn v adresáři /usr/src/redhat/RPMS/i38­6. Druhým nejčastějším případem bývá umístění v adresáři /usr/src/redhat/RPMS/no­arch, kam „padají“ balíčky, které nejsou závislé na konkrétní hardwarové platformě (skripty, data, atd.).

Tento postup má ale jednu zásadní nevýhodu. Nevyřešíte tak problém, kdy je například při kompilaci třeba přidat nějaké parametry, nastavit cesty a podobně. Abyste podobné věci mohli provádět, potřebujete k tomu už malinko více vědomostí o formátu RPM. Minimálně to, že při tvorbě balíčku se používá tak zvaný spec soubor (obvykle jméno_programu­.spec, např. balicek1.spec). Ten je obsažen ve zdrojovém balíčku a v podstatě popisuje vše od kompilace až po umístění souborů při instalaci.
Pokud tedy budete chtít ovlivnit takřka cokoliv, stačí aplikovat následující postup. Balíček se zdrojovými kódy nainstalujete stejně jako binární. Zmiňovaný spec soubor najdete v adresáři /usr/src/<jmé­no distribuce>/SPECS a zdrojové kódy v /usr/src/<jmé­no distribuce>/SO­URCES. Nyní se nekladou meze vaší fantazii. Můžete upravit lokace souborů, změnit parametry kompilace, přejmenovat balíček nebo přímo modifikovat zdrojové kódy. Detailními postupy se zde nebudu nyní zaobírat, protože jenom samotný popis možností spec souboru by vystačil na samostatný článek (a nebo knihu :). Mohu jen říci, že pokud umíte kompilovat ze zdrojových kódů pomocí „svaté trojice“ ./configure, make, make install, tak ve spec souboru většiny balíčků rychle najdete, co potřebujete.
Tak, teď máte upravený balíček a je na vás, co s ním provedete. Většinou je to buď opětovné vytvoření (upraveného) zdrojového balíčku, kompilace a vytvoření binárního balíčku a nebo obojí. K tomu slouží tři parametry: -bs (build source), -bb (build binary) a -ba (build all). Měl bych podotknout, že nový zdrojový balíček se uloží do adresáře /usr/src/<jmé­no distribuce>/SRPMS. Podstatné je, že jako další parametr nepředáváte rpm jméno souboru nebo balíčku, ale přímo konkrétní SPEC soubor. Pokud tvoříte binární balíček, doporučil bych ještě přidat volbu –clean, která zajistí, že stejně jako při použití –rebuild budou odstraněny všechny průběžně vznikající soubory. To je pro začátek o kompilování vše.

Příklady

Rychlé vytvoření binárního balíčku:
rpm –rebuild balicek-1.0–2.src.rpm

Vytvoření binárního balíčku s úpravou kompilačních parametrů v distribuci Red Hat Linux:
rpm -i balicek-1.0–2.src.rpm
cd /usr/src/redhat/SPECS
úprava souboru balicek.spec (může být i přidání patche atd.)
rpm -bb balicek.spec


ZÍSKÁVÁNÍ INFORMACÍ Z DATABÁZE BALÍČKŮ

Jak jsem se již několikrát zmínil, rpm si ukládá informace o nainstalovaných balíčcích do systémové databáze. Z této databáze, jakož i přímo z rpm souborů lze zjistit mnoho zajímavého a užitečného a právě na to se teď zaměříme.

Pro dotazování je v rpm vyhrazen přepínač -q (od slova query). Ten sám o sobě ale nic nedělá, jenom říká, že se budeme ptát. Vždy je k němu třeba doplnit ještě další parametr, který určuje, na co se vlastně ptáme. První, co asi většinu uživatelů napadne, je vypsání seznamu všech instalovaných balíčků. K tomu slouží parametr -a, jako all:

rpm -qa

Chceme-li třeba zjistit verzi některého balíčku, jehož jméno nevíme tak docela přesně, lze to provést takto:

rpm -qa | grep jmeno

Dalším užitečným parametrem je -f. Ten umožňuje zjistit, který balíček vlastní daný soubor. Například

rpm -qf /bin/cat

nám prozradí, že cat je součástí balíčku textutils.

Souhrnné informace o balíčku lze vypsat pomocí přepínače -i. Jako další parametr očekává rpm jméno balíčku:

rpm -qi textutils-1.22j-10

vypíše něco takového:

Name        : rpm                      Relocations: (not relocateable)
Version     : 3.0.3                    Vendor: Red Hat Software
Release     : 6x                       Build Date: Tue Oct 5 17:57:28 1999
Install date: Wed Dec 29 12:06:02 1999 Build Host: porky.devel.redhat.com
Group       : System Environment/Base  Source RPM: rpm-3.0.3-6x.src.rpm
Size        : 2904955                  License: GPL
Packager    : Red Hat Software <http://developer.redhat.com/bugzilla>
Summary     : The Red Hat package management system.
Description :
The Red Hat Package Manager (RPM) is a powerful command line driven
package management system capable of installing, uninstalling,
verifying, querying, and updating software packages.  Each software
package consists of an archive of files along with information about
the package like its version, a description, etc.

Kromě verze či autora se z výpisu dozvíte i kdy a kde byl balíček vytvořen, pod jakou licencí je šířen, do jaké kategorie spadá a také toto info často obsahuje krátký popisek. Podotýkám, že tyto údaje lze zjišťovat i jednotlivě, ale to už je opět na delší povídání. Zájemce o samostudium odkazuji na man rpm, přepínač –queryformat.

Několika dalšími užitečnými parametry se již nebudu zaobírat detailně, pouze je zmíním. -R vypisuje seznam závislostí pro daný balíček, -l vypíše kompletní seznam souborů z balíčku, -c vypíše seznam konfiguračních souborů a -d seznam souborů dokumentace (velmi užitečné). Pokud ke všem těmto (i některým dalším) přepínačům přidáte ještě -p, můžete získávat informace o nenainstalovaných balíčcích. Místo jména balíčku je je pak samozřejmě třeba předávat jméno rpm souboru (např. rpm -qpl balicek-1.0–2.i386.rpm).


VERIFIKACE

Zatím jsem opomíjel ještě jednu důležitou funkci rpm, a to je verifikace balíčků, jejímž cílem je odhalit chybějící či modifikované soubory. K tomu slouží přepínač -V, případně -y. Dodatečnými parametry lze nastavit, aby rpm neinformovalo o smazaných souborech (–nofiles), případně o souborech, jejichž MD5 kontrolní součet se změnil (–nomd5). Při kontrole se vypisují pouze změněné soubory, přičemž změna je vyjádřena osmiznakovým řetězcem. Každý znak buď obsahuje tečku, pokud nebyl daný atribut změněn nebo písmeno, značící že ke změně došlo. Jednotlivé znaky mají tyto významy:

Po parametru -V je očekáván přepínač -a, který říká, že se mají kontrolovat soubory ze všech instalovaných balíčků, a nebo jméno konkrétního balíčku.


Tím jsme si popsali nejčastěji používané parametry a volby, které můžete při práci s RPM potřebovat, při jejichž znalosti by vás neměl potkat žádný zásadní problém. RPM toho ovšem umí ještě více a třeba o problematice tvorby balíčků by se daly popsat stohy papíru. Pokud se rozhodnete pronikat do rpm ještě hlouběji, doporučuji začít jeho na domovské stránce.

Všechny informace uvedené v tomto článku se vztahují k RPM verze 3.0.3 a ne všechny platí i pro starší verze, i když většina asi ano.

P.S. Pokud se najde nějaký debianista, který by podobným způsobem rozebral práci s deb balíčky, jenom to uvítáme. I package management může být jedním závažíčkem na misce vah při rozhodování, kterou distribuci zvolit.