Rukověť baliče RPM - V (Zdrojové soubory)

16. 6. 2005 | David Nečas | Návody | 8275×

Dokončení popisu položek hlavičky, formátování seznamu změn a představení nesouborů, nezdrojů a nepatchů.

Metadata

V úvodní části jsme probrali některé informativní položky hlavičky (metadata), a teď nastal čas na ty zbývající. Žádná z nich není povinná.

URL

Domovská stránka programu, případně jiné URL, kde o něm lze nalézt další informace.

Copyright

Alias pro License, který se dříve používal.

Packager

Kdo balíček zabalil. Nepíše se obvykle do spec souborů, ale namísto toho definujeme v ~/.rpmmacros makro %packager, které přebíjí hodnotu ze spec souboru.

Distribution

Distribuce, do níž balíček patří. Opět ji obvykle nepíšeme do spec souboru, ale definujeme makro %distribution.

DistURL

URL distribuce, tj. URL, kde se můžeme dovědět více o distribuci samé. V ~/.rpmmacros ji definujeme jako %disturl.

Vendor

Obchodník, distributor. Firmy vydávající distribuce tam píší něco jako Red Hat, Inc., ostatní, co je napadne, případně nic. Používáme-li tuto hlavičku, obvykle ji máme definovanou jako %vendor v ~/.rpmmacros.

Icon

Ikona. Ignorujte, neboť to je přesně to, co dělají i všechny programy.

Sekce %changelog

Záznam změn (changelog) je nepovinná sekce spec souboru, tradičně bývá poslední. V distribučních spec souborech je standardní až povinná; u spec souborů našich vlastních programů je zase často logičtější psát i změny v nich do společného záznamu změn, tudíž ji u nich možná nevyužijeme.

Typický záznam změn vypadá

%changelog
* Fri Oct 29 2004 Jeremy Katz <katzj@redhat.com> - 2.1.11-2
- add patch to fix multilib updates on ia32e (#135396)

* Thu Oct 28 2004 Jeremy Katz <katzj@redhat.com> - 2.1.11-1
- update to 2.1.11
  - fix config file error handling
  - better handling of empty lines/comments in mirror lists
  - improve some error messages
…

RPM samo vynucuje jen několik málo pravidel formátování záznamu změn:

• Každý záznam začíná hvězdičkou * (jako prvním nemezerovým znakem na řádku).
• Po hvězdičce následuje datum ve formátu %a %b %e %Y.
• Zbytek řádku je „jméno“, na které už ale nejsou kladeny žádné požadavky (kromě neprázdnosti), takže tam borci z RedHatu běžně píší i verzi, jak vidíme v příkladu.
• Další řádky, jsou-li nějaké, obsahují popis změny. Nejsou na ně kladeny žádné požadavky – kromě toho, že vcelku logicky nemohou začínat hvězdičkou.
• Změny jsou uspořádány sestupně podle data.

Jednotlivé distribuce si ovšem mohou zavést přesnější pravidla, co a jak se má do záznamu změn psát.

Zdrojové soubory a patche

Při balení vlastních programů si vystačíme s tarovou koulí se zdrojovým kódem, ale cizí programy píší vždy prasata a je zapotřebí je patchovat či k nim doplnit další soubory, např. init skripty pro naši oblíbenou distribuci. Kam je napíšeme, když je položka Source hlavičky jen jedna?

Není. Nic totiž není tak jednoduché, jak to napíši. Ve skutečnosti máme k disposici pro zdrojové kódy tolik položek hlavičky, kolik je přirozených čísel, což by mělo obyčejně stačit. Jmenují se Source0, Source1, Source2 atd., naše známá Source je přitom jen alias pro Source0, který vypadá lépe, když máme jen jeden zdrojový soubor.

Podobně existují pro patche položky Patch0, Patch1, Patch2 atd. a Patch je alias pro Patch0. Zde je ovšem méně užitečný než u zdrojových kódů, protože stejně jako neštěstí nechodí patche nikdy samy. Zdrojové soubory a patche nemusíme číslovat sekvenčně, můžeme třeba od nuly číslovat patche opravující chyby při kompilaci, od 100 bezpečností opravy a od 533 dodatečné vlastnosti a přizpůsobení distribuci. Hlavička se tak může rozrůst na

Source0: ftp://ftp.example.com/pub/lobster/%{name}-%{version}.tar.bz2
Source1: lobster.init
Patch0: lobster-1.8-broken-makefile.patch
Patch1: lobster-1.7-missing-includes.patch
Patch8: lobster-1.10-CAN-1620-1108.diff

Jména jednotlivých zdrojových souborů a patchů (včetně cesty) jsou přístupná jako automaticky definovaná makra %{SOURCEn} a %{PATCHn}. Init skript lobster.init tudíž nainstalujeme

%install
…
mkdir -p -m 755 $RPM_BUILD_ROOT/etc/init.d
install -p -m 755 %{SOURCE0} $RPM_BUILD_ROOT/etc/init.d/lobster

a samozřejmě ho přidáme do sekce %files.

Patche

Patche bychom mohli aplikovat podobně, ale to by nebylo RPM, kdyby na to nebylo nějaké makro. Jmenuje se %patchn, aplikuje na zdrojový kód patch číslo n a jako argumenty mu můžeme dát některé volby programu patch(1). Konkrétně -pm (úroveň patche m, tj. odstranit ze začátku cesty m adresářů), -z či -b (zálohovací koncovka), -R (aplikovat obrácený patch) a -E (vynucené smazání souborů, když jsou opatchovány na prázdné).

%prep
%setup
%patch0 -p1 -b .broken-makefile
%patch1 -p1 -b .missing-include
%patch8 -p0 -b .CAN-1620-1108

Používat pro každý patch jedinečnou zálohovací koncovku se vyplatí. Dokud se vše aplikuje v pořádku, tak na nich nezáleží. Jakmile však něco neprojde – a ono samozřejmě neprojde, když máte tři sta patchů na jeden textový editor – zvyšují naši šanci se zorientovat, a zejména naši šanci aplikovat vzpouzející se části patche ručně a přegenerovat ho pomocí utility gendiff(1) – která by mimochodem mohla fungovat lépe.

Makro %patch také pozná patche komprimované gzipem či bzipem2 a samo si je před aplikací rozbalí.

Nezdroje a nepatche

Říkal jsem už, že nic není tak jednoduché, jak to napíši? Kromě zdrojových souborů a patchů existují také zdrojové nesoubory a nepatche. Liší se od nich tím, že se nebalí do zdrojového rpm. V hlavičce uvádíme jejich čísla do zvláštních položek NoSource a NoPatch.

Source0: ftp://ftp.example.com/pub/lobster/%{name}-%{version}.tar.bz2
NoSource: 0

Zdrojové rpm ze spec souboru s hlavičkami NoSource či NoPatch je pak nezdrojové a má koncovku .nosrc.rpm namísto .src.rpm. Nelze je samozřejmě překompilovat do binárního, dokud chybějící zdroje a patche do adresáře SOURCES ručně nedoplníme.

V distribucích se s nezdrojovými balíčky nesetkáme. Chceme-li však třeba poslat někomu vše, co je zapotřebí k zabalení rpm Gimpu (což nejspíš nebude jen samotný spec soubor), ale bez 12MB tarové koule, již si může stáhnout kdekoli, je nezdrojové rpm ideální řešení.

       

Komentáře

[Michal Marek (twofish)]

Nic totiž není tak jednoduché, jak to napíši. Ve skutečnosti máme k disposici pro zdrojové kódy tolik položek hlavičky, kolik je přirozených čísel, což by mělo obyčejně stačit.

Patchů a zdrojáků může být jen tolik, kolik nezáporných čísel může nabývat int (typicky ušmudlaných 2^31), a to je ještě počítají dohromady (!), takže pozor na to

[Michal Marek (twofish)]

Vlastně ještě o jedna míň

[Zdeněk Burda]

to je blbý, to mi na můj projekt Kalkulačka 0.1 nemůže nikdy stačit.

[unchallenger]

Hm, ona to stejně není pravda -- nedávno jsem při čtení zdrojáku zjistil, že je tam zadtrátováno nějaké omezení, takže je jich ve skutečnosti mnohem méně. Ale už mi vypadlo, kolik to maximální číslo je.

[Pavel Janousek]

No rekneme, ze to omezeni neni tak drasticke, kdyz staci i Linux kernelu - aneb vite o nejakem src.rpm, ktery by byl vice zazaplatovany?

[unchallenger]

Na Vim 6.2 vydal jen Bram sám 532 patchů.

[Jara]

abych moh dynamicky menit misto buildu udelal jsem si skript ktery vytvori soubor 'mojemakra' obsahujici akorat presmerovanej %_topdir. pak vygeneruje mojerc ktere obsahuje macrofiles:puvodni_seznam_maker:mojemakra. pak sestavuju rpm pomoci rpmbuild --rcfile=mojerc.

vsechno funguje jak ma pokud neuvedu arch jine nez defaultni i686. chtel jsem udelat arch: noarch a zahlasilo to neco jako 'no compatible architecture found to build'. pri blizsim patrani jsem zjistil ze --showrc mi vraci radek: compatible build archs: i686 zatimco kdyz nepouziju moje nove --rcfile=mojerc tak vraci compatible build archs: athlon i686 i586 i486 i386 noarch fat

tusi nekdo kam se vsechny architektury tim jednoduchym presmerovanim podely?

[unchallenger]

IIRC se soubory uvedené v --rcfile se čtou namísto výchozích, ne navíc k nim. V tvém případě bych na rcfile vůbec nehrabal a spouštěl rpmbuild --define '_topdir /bla/bla'.

[Michal Čihař]

Třeba v SUSE se s nimi setkáme, viz ftp://ftp.suse.com/pub/suse/i386/9.3/suse/nosrc/

[unchallenger]

Zajímavé. A čím se řídí, od čeho se vydává nosrc?

[Michal Čihař]

Třeba velké věci, kde jde akorát o přesunutí souborů z tarballu do rpm (dokumentace - wxGTK-doc nebo data ke hrám - pysol, fillets-ng-data), ušetří se tím dost místa a uživatel v podstatě o nic nepřijde.

[unchallenger]

To by mohlo vysvětlit některé položky. Ale takové nosrc.rpm teTeXu má cca 60 MB, kdežto plné src.rpm má cca 90 MB. Relativní úspora nic moc.

[Michal Čihař]

Tak na to se mě neptej, prozradil jsem co vím

[Miloslav Trmac]

s/RedHat/Red Hat/

[unchallenger]

Jméno firmy je tam správně: Red Hat, Inc.

A neformální označení? Nemají psát své logo redhat. Pak to dopadá tak, že na red hat Google nabízí opravu redhat.

[Jan Martinek]

V rpm-4.4 ten alias už nefunguje. Povinně vyžaduje označení License, jinak zařve něco jako

error: Legacy syntax is unsupported: copyright
error: line 8: Unknown tag: Copyright: GPL

[Triton]

ale cizí programy píší vždy prasata a je zapotřebí je patchovat či k nim doplnit další soubory

Asi je vaše množina používaných programů disjunktní s tou mojí.

Ale jako laciná provokace dobrý ...

[Michal Marek (twofish)]

Dá se nějak v --qf rozlišit nosrc balíček od src balíčku? Něco jako

rpm --qf '%|nosource?{no source}:{source}|\n' -p *src.rpm

což ale nefunguje. V lib/rpmlib.h je

    RPMTAG_NOSOURCE		= 1051, /*!< internal */
    RPMTAG_NOPATCH		= 1052, /*!< internal */

znamená to že se ta informace do hlavičky neuloží?

[unchallenger]

Tato otázka mě tedy nikdy nenapadla, protože to normálně poznám podle názvu souboru...

rpm -q --qf='[%{FILENAMES} %{FILEFLAGS:fflags}\n]' -p foobar.src.rpm

Pokud to u nějakého souboru vypíše ,g` (ghost, bude v devátém dílu), tak je to nezdrojový soubor. Když to u žádného nevypíše, tak je src.rpm všechny obsahuje. Nic lepšího asi neexistuje.

[Michal Marek (twofish)]

Aha, takže nosrc jsou vlastně ghost soubory, to jsem nevěděl. Já to ani k ničemu nepotřebuju, jenom mě to tak napadlo

[yeti]

Typo

-install -p -m 755 %{SOURCE0} $RPM_BUILD_ROOT/etc/init.d/lobster
+install -p -m 755 %{SOURCE1} $RPM_BUILD_ROOT/etc/init.d/lobster