Rukověť baliče RPM - XIV (Přizpůsobení)

18. 8. 2005 | David Nečas | Návody | 5239×

Volitelná kompilace součástí, přemístitelná rpm, lokalizace.

Volitelná kompilace součástí

Portage má USE flagy, RPM má zase makra, a tak si můžeme USE flagy implementovat sami. Není k tomu zapotřebí žádná zvláštní podpora ze strany rpmbuildu. Mechanismus, jenž nyní popíši, se zatím nepoužívá ani příliš široce ani obzvlášť systematicky, avšak existuje.

Ruční metoda

Nejrpve určíme makro, řekněme %with_sandals, které má řídit kompilaci podpory libsandals do balíčků. Pak upravíme spec soubory, aby se do programů zakompilovala podpora libsandals, má-li %with_sandals hodnotu 1, a nezakompilovala, má-li hodnotu 0. To mimo jiné obnáší úpravu BuildRequires

%if %with_sandals
BuildRequires: libsandals-devel
%endif

předání správných parametrů configure

%configure \
%if %with_sandals
  --with-sandals \
%else
  --without-sandals \
%endif

a podobné úpravy Provides či v sekci %files. Častý obrat je též vytvoření vedlejšího balíčku, jenž je celý podmíněný:

%if %with_sandals
%package sandals
Summary: Supplementary sandals for lobster
…

%description sandals
…
%endif

Další postup záleží na poměru naší lenosti a megalomanie.

V nejjednodušším případě přidáme na začátek spec souboru

# Define to 1 to enable sandals
%define with_sandals 0

a s pocitem dobře vykonané práce se půjdeme věnovat nečemu jinému, například odpočinku. Podobných spec souborů můžeme potkat spousty.

Kdo bude ovšem chtít takové zdrojové rpm překompilovat s jinou hodnotou %with_sandals, musí upravit spec soubor. To není právě praktické. Změníme proto alespoň definiční řádek na potlačitelnou implicitní hodnotu:

%{!?with_sandals:%define with_sandals 0}

Nyní už může uživatel zapnout podporu sandálů jak jednorázově při kompilaci:

rpmbuild --define 'with_sandals 1' -bb lobster.spec

tak trvale definicí v ~/.rpmmacros:

%with_sandals 1

Moderní přístup

Novější verze RPM, tj. alespoň 4.4, přímo podporují volby --with sandals a --without sandals, jež definují makra %_with_sandals, resp. %_without_sansals, a můžeme tak jednoduše spouštět

rpmbuild --with sandals -bb lobster.spec

Ve skutečnosti tedy RPM nic přímo nepodporuje, uvedené dvě volby jsou jen aliasy popt pro --define, definované v /usr/lib/rpm/rpmpopt-verze, které si můžeme do staršího rpm případně doplnit sami (nebudeme ovšem měnit tento soubor, ale doplníme je do /etc/popt).

Stále však cosi schází – volba --with sandals vytvoří makro %_with_sandals, kdežto my bychom rádi %with_sandals. A také musíme zpracovat negativní argument --without sandals. Tedy nemusíme, protože implicitní je kompilace bez sandálů, a tak můžeme v tomto případě --without sandals klidně ignorovat, ale potřebovali bychom ji zpracovat, kdyby se implicitně sandály zakompilovávaly.

Chybějící dílek skládačky doplňují standardní makra %bcond_with a %bcond_without:

%define bcond_with()    %{expand:%%{?_with_%{1}:%%global with_%{1} 1}}
%define bcond_without() %{expand:%%{!?_without_%{1}:%%global with_%{1} 1}}

Porozumění definicím si necháme na dlouhé zimní večery a zaměříme se na praktické použití. Volitelnou součást balíku deklarujeme jedním z následujících způsobů:

%bcond_with sandals
%bcond_without sandals

První přitom použijeme, má-li --with sandals zapínat implicitně vypnutou podporu sandálů; druhou pak, má-li --without sandals vypínat implicitně zapnutou podporu. V obou případech se pak řídíme existencí makra %with_sandals. Abychom to měli ještě jednodušší, byla zavedena makra %with a %without (vidíme, že to jsou jen specializované varianty %defined a %undefined)

%define with()    %{expand:%%{?with_%{1}:1}%%{!?with_%{1}:0}}
%define without() %{expand:%%{?with_%{1}:0}%%{!?with_%{1}:1}}

s nimiž můžeme psát čitelné podmínky

%if %{with sandals}
…
%endif

Jsme-li osamělí baliči, na další stupínek megalomanie už nedosáhneme. Tvoříme-li však distribuci, můžeme se pokusit udělat ve with_… makrech pořádek, aby každý balíček nepoužíval, jaká jeho autora zrovna napadla, zdokumentovat je a definovat standardní formu, jak a kam se do spec souboru píší, abychom usnadnili zjišťování, která daný spec soubor podporuje (od rpm lze stěží očekávat, že je dokáže vypsat, když o žádných %with_… nemátušení).

Přemístitelná rpm

Přemístitelné (relocatable) balíčky mohou být nainstalovány do jiného než implicitního adresáře (obvykle /usr) pomocí volby --prefix, případně podrobněji --relocate starý_adresář=nový_adresář. Kupříkladu

rpm -ivh --prefix /opt/lobster lobster-1.10-1.i386.rpm

nainstaluje lobster do /opt/lobster namísto do /usr.

Postavíme-li si hlavu, můžeme, pravda, nainstalovat cokoli kamkoli s volbou --badreloc, ale následky padají na naši hlavu. Balíčky, jež přemístitelnost samy deklarují, by měly po instalaci do jiného adresáře i fungovat.

Přemístitelný balíček vyrobíme přidáním položky Prefix do hlavičky. Ta jednak deklaruje, že se všechny soubory instalují do tohoto adresáře – to rpmbuild kontroluje a obsahuje-li balíček soubory i v jiných adresářích, kompilace selže. A jednak určuje, který adresář bude nahrazen hodnotou z --prefix při případném přemístění. Typická deklarace vypadá

Prefix: %{_prefix}

Instaluje-li se rpm i do dalších adresářů, např. /etc, ale je přitom přemístitelné (to není právě obvyklá situace), můžeme uvést několik hlaviček Prefix, pro každý adresář jednu, a při přemisťování si pak už nejspíš nevystačíme s --prefix a musíme použít --relocate. Ve starších verzích pro to existovala položka Prefixes, dnes je ale synonymní s Prefix.

Zda nějaký program je či není možné po kompilaci pro určitý prefix přemístit, samozřejmě závisí na tom, jak hledá své komponenty a jak ho využívají další programy. Není-li přemístitelný sám od sebe, položka Prefix to sama magicky nezařídí, proto se při jejím přidávání musíme zamyslet, bude-li program po přemístění opravdu fungovat.

Lokalizace

Metadata balíčku lze lokalizovat, takže se pak uživateli např. při rpm -qi vypíší informace v jeho rodném jazyce. Smysluplnost tohoto kroku je zapotřebí zvážit. Jednak mají lokalizované informace tendenci rozcházet se s originálem, za druhé je kupříkladu celý zbytek výstupu rpm -qi prakticky nelokalizovatelný, neboť je to alias popt pro rpm -q --qf=… se správným formátem – frontendy k RPM toto omezení, pravda, mít nemusejí.

Položky hlavičky lokalizujeme přidáním jména jazyka do závorky za její název:

Summary: A poor human doctor emulator
Summary(cs): Ubohá napodobenina lidského lékaře

Lokalizovat lze tyto položky hlavičky: Summary, Group, Requires, PreReq, BuildPrereq, BuildRequires. Skupinu je ovšem nesmysl překládat ve spec souboru každého balíčku znovu (a nejlépe pokaždé jinak), a k čemu má sloužit lokalizace závislostí, netuším (balíček vyžaduje sjednocení množin závislostí uvedených pro všechny jazyky). Zbývá tedy stejně jen Summary.

Jediná další věc, již lze přeložit, je sekce %description. Název locale pak uvádíme volbou -l:

%description -l cs
…

       

Komentáře

[Peter Rychnavsky]

Dlhší čas sledujem tento seriál a veľmi mi pomohol, teda by som chcel poďakovať autorovi za peknú prácu.

[kocour_easy]

Dobry den, take dekuji za Vase clanky. Mam dotaz, kdyz si vytvorim spec-file a dam spustit vytvoreni daneho rpm-ka, vse probehne v poradku, ale protoze mam zle sdefinovanou polozku v sekci %files take rpm-ko se mi nevytvori. Protoze dane vytvoreni(zkompilovani) trva dlouho dobu(treba kompilace kde), neni nejake reseni, procedury %build->%install preskocit a spustit rovnou proceduru %files. Dekuji

[Pavel Janousek]

A co poprvnim buildu a kdyz rpmbuild zarve udelat toto:

rpmbuild -bi --short-circuit SPEC

tim docilime toho, ze se to cele nekompiluje (pac to uz jsme uspesne absolvovali), pouze se pokusi to instalovat do "chrootu" a pote se zkontroluji zavislosti. V podstate se da rici, ze se provede vse az do okamziku zapisu ...i386.rpm apod. Bohuzel je zamer, ze nejdou po oprave SPEC filu vytvorit RPMka primo z takoveho mezisystemu, protoze se snahou, aby vytvorene RPM soubory byly produktem deterministickeho procesu = nezmenenho SPEC souboru a musi tedy projit rpmbuild --rebuild ... nebo rpmbuild -bb SPEC.

Presto to muze podstatne urychlit praci, nicmene se dvoji kompletni kompilaci nevyhneme (coz treba u OpenOffice, opravdu potesi).

Ja spise resim jiny problem, evidentne az novejsimu RPM systemu vadi, ze po instalaci do chrootu zustanou nejake polozky, ktere nemaji zadny obraz ve files sekcich... (a tedy nebudou do RPMkem zahrnuty). Novejsi RPM system na to upozornuje a odmita dokoncit vytvoreni RPMek, je nejaky zpusob, jak zabranit fatalnimu ukonceni? (vesmes se jedna o cosi, co sice via make install je nainstalovano, ale nikdo to nechce a tak pred %clean mi nezbyva nic jineho nez rm -f $RPM_BUILD_ROOT/soubor(y)...)

[Miroslav Prýmek]

Tahle vlastnost me taky pekne nastvala, zvlast kdyz to bylo po kompilaci KOffice :) Nechapu, kdo na to prisel? Warning by uplne stacil, ale ukoncit vyrobu balicku? ufff...

Nicmene nastesti vse resi makro %_unpackaged_files_terminate_build 0

viz http://www.rpm.org/hintskinks/unpackaged/

[Espinosa]

Presto to muze podstatne urychlit praci, nicmene se dvoji kompletni kompilaci nevyhneme (coz treba u OpenOffice, opravdu potesi).

..no to ste mě teda nepotěšil, právě mi spadlo vytváření vlastního balíčku OpenOffice V samém závěru na jedné chybičce %files Po 20ti hodinach buildovani! Tak dám rpmbuild -bi --short-circuit a pořád hledám ty balíčky...