M4r3k’s web

Written by m4r3k and tagged by články, openSUSE, packages.

Výběr repozitářů, do kterých bude nově sestavený balíček přidán. Řešení závislostí a přebírání balíčků z repozitářů určených pro jiné distribuce.

Přidáváme repozitáře, pro které chceme balíček sestavit

Přidáme si tedy repozitáře, pro které chceme balíček sestavit. To můžeme udělat například pomocí osc -e prj home:m4r3k, přičemž se nám opět spustí $EDITOR. Do něj pak napíšeme kód podobný tomu následujícímu:

<project name="home:m4r3k">
  <title>m4r3k's Home Project</title>
  <description>My packages :-).</description>
  <person role="maintainer" userid="m4r3k"/>

  <repository name="openSUSE_10.3">
    <path project="openSUSE:10.3" repository="standard"/>
    <arch>i586</arch>
    <arch>x86_64</arch>
  </repository>

</project>

Jak vidíte, tento soubor má poměrně složitou syntaxi (alespoň já si ji ne a ne zapamatovat :-)), naštěstí se však repozitáře dají přidat i pomocí webového rozhraní. Přihlásíme se tedy na build.opensuse.org, v našem domovském projektu klikneme na tlačítko Add Repository a vybereme si některý z repozítářů, pro které chceme sestavovat. V našem příkladu se jedná o repozitáře openSUSE 10.3, Fedora 8 a Mandriva 2008.

Po přidání repozitářů se nám začnou sestavovat jednotlivé balíčky. Průběh sestavování si můžeme vypsat pomocí příkazu osc buildlog distribuce architektura, například tedy:

osc buildlog openSUSE_10.3 i586

Po nějaké době by nám měly vzniknout balíčky pro distribuce openSUSE, Fedora a Mandriva. Každá by měla obsahovat jeden textový soubor umístěný v adresáři /etc/ s příslušným jménem. To si můžeme zkontrolovat tak, že si sestavené balíčky stáhneme a pomocí rpm -qlp balíček.rpm necháme vypsat jejich obsah.

for foo in *.rpm; do echo "balíček $foo obsahuje"; rpm -qlp $foo; echo "---"; done

balíček fedora-testovaci-balik.rpm obsahuje
warning: fedora-testovaci-balik.rpm: Header V3 DSA signature: NOKEY, key ID a575c4b8
/etc/Fedora.txt
---
balíček mandriva-testovaci-balik.rpm obsahuje
warning: mandriva-testovaci-balik.rpm: Header V3 DSA signature: NOKEY, key ID a575c4b8
/etc/Mandriva.txt
---
balíček openSUSE-testovaci-balik.rpm obsahuje
warning: openSUSE-testovaci-balik.rpm: Header V3 DSA signature: NOKEY, key ID a575c4b8
/etc/openSUSE.txt
---

Poněkud pokročilejší podmínky

Mezi verzemi distribucí se často přejmenovávají, rozdělují a slučují balíčky. Proto je výhodné mít k dispozici i rozlišování podle verze jednotlivých distribucí. Například, pokud chceme, aby se nějaká část kódu provedla jen v případě, že jde o distribuci openSUSE a zároveň se jedná o verzi novější než 10.2, pak použijeme tento kód:

%if 0%{?suse_version} > 1020
	%patch0
%endif

Tabulka proměnných pro jednotlivé distribuce

Tabulka převzata, upravena a aktualizována z en.opensuse.org.

Porovnávací operátory nejsou samozřejmě omezeny jen na operátor ekvivalence (==), ale také jsou k dispozici operátory menší než (<) a větší než (>). Tyto operátory můžeme také skládat a sestavit tak operátor větší nebo rovno (>=), případně menší nebo rovno =<). Stejně tak můžeme také kombinovat jednotlivé podmínky a sestavit například následující konstrukci:

%if 0%{?suse_version} || 0%{?sles_version}
 %patch1 -p1
%endif

Která provede makro %patch vždy, když je balíček sestavován v prostředí openSUSE nebo SLES(D). U sestavování balíčků se lze také rozhodovat podle architektury a tyto podmínky lze samozřejmě také kombinovat ve složitější celky. Například takto:

%if 0%{?suse_version} == 1030
%ifarch x86_64
 %patch1
%endif
%endif

Makro %patch1 bude provedeno, jen když je balíček sestavován pro openSUSE verze 10.3 a cílová architektura je x86_64.

Kde sehnat závislosti?!

Často se stane, že si chcete udělat balíček na nový program a z ničeho nic zjistíte, že programů, na kterých tento program závisí, je obrovská spousta. To je ještě v pohodě, jednoduše je napíšete do BuildRequires nebo do Requires. V tom horším případě však zjistíte, že potřebné balíčky nejsou k dispozici v oficiálních stromech balíčků. Pokud máte štěstí, tak balíček který potřebujete, už vytvořil někdo jiný, kdo připravuje balíčky v rámci openSUSE Build Service. Pak máte několik možnosti, jak tyto balíčky zužitkovat. Můžete je zkopírovat do svého projektu pomocí příkazu osc copypac, který má následující syntaxi:

osc copypac home:jiny-balikar cool-balicek home:m4r3k cool-balicek

Což vytvoří identickou kopii balíčku u vás v home:m4r3k. To se hodí v případě, že hodláte balíček nějak významněji upravovat. Má to však tu nevýhodu, že zbytečně plýtváte strojový čas i místo na build serverech. Proto je k dispozici také příkaz osc linkpac, který provede nalinkování balíčku z jednoho projektu do jiného. Tam se balíček sestaví a bude k dispozici i pro váš projekt. Toto řešení také nabízí určitou míru volnosti. Pokud totiž ve svém nalinkovaném projektu vytvoříte soubor se stejným názvem jako je v tom původním, tak se použije ten váš. Můžete si tak třeba poupravit .spec soubor, aniž by se muselo udržovat několik kopií tarové koule se zdrojovými kódy.

osc linkpac home:jiny-balikar cool-balicek home:m4r3k cool-balicek

Vlastní .spec soubor vnutíte projektu tak, že si aktualizujete svou lokální kopii repozitáře pomocí příkazu osc up a přepnete se do adresáře s balíčkem (cd cool-balicek). Pak si vytvoříte třeba soubor cool-balicek.spec a v něm vlastní obsah. Častěji však využijete už hotový .spec soubor a jen si jej upravíte k obrazu svému. Stažení originálního souboru lze provést pomocí:

osc co home:jiny-balikar cool-balicek cool-balicek.spec

Nyní už stačí soubor jen otevřít ve svém oblíbeném editoru a dle libosti upravit. Soubor poté přidáme do projektu pomocí osc add cool-balicek.spec a výsledek pošleme na server pomocí osc commit. Balíček se nyní sestaví i s vašimi změnami. Tento způsob sice už tolik neplýtvá místem na disku, ale na druhou stranu stále plýtvá strojovým časem serverů. Proto je k dispozici i příkaz osc aggregatepac, který je vhodný v případě, že chceme balíček jen používat a nijak upravovat. Syntaxe je obdobná jako u předchozích příkazů.

osc aggregatepac home:jiny-balikar cool-balicek home:m4r3k cool-balicek

Stejně jakou u předchozích dvou příkazů, je i u tohoto příkazu poslední parametr cool-balicek nepovinný a v případě, že jej nepoužijete, tak se použije název stejný jako u zdrojového balíčku.