OBS - 3 (backportujeme kernel a další balíčky)

2. 7. 2008 | Mark Stopka

Články - OBS - 3 (backportujeme kernel a další balíčky)  

Pokud chcete dostat do své verze distribuce novější jádro, které ještě není v repozitáři, bude se vám hodit umět s pomocí openSUSE Build Service backportovat. Kromě toho se naučíte obyčejné patchování balíčků.

openSUSE (a pokud vím i všechny ostatní RPM-based distribuce) fungují na principu stabilních vydání, a ne na principu rolling-updates, jako je tomu třeba v případě Gentoo. Proto, když chcete novou verzi nějakého programu (třeba jádra), tak musíte buď přejít na aktuální vývojovou verzi (např. openSUSE Factory), nebo si patřičný balíček backportovat. (Je zde ještě možnost si program zkompilovat mimo balíčkovací systém, ale to je spíš cesta do pekel než elegantní řešení problému.)

S buildservicem však není nic snažšího, než si takový balíček (třeba jádro jako v našem případě) backportovat. Můžete provádět rozličné backportování. Můžete si do svého openSUSE 10.3 naládovat jádro z openSUSE 11.0 nebo přímo z openSUSE Factory. Například jsem pořeboval na desktop HP dc5800 dát novější jádro, aby mi správně fungovalo ACPI. S buildservicem stačilo vytvořit nový projekt home:m4r3k:kernel-backport (je zbytečné si zaneřádit domácí projekt, když je tu ta skvělá možnost vytvářet podprojekty) pomocí příkazu:

osc meta prj -e home:m4r3k:kernel-backport

V nabídnutém XML souboru:

<project name="home:m4r3k:kernel-backport">
	 <title>Short title of NewProject</title>
  <description>This project aims at providing some foo and bar.
It also does some weird stuff.
</description>
  <person role="maintainer" userid="m4r3k" />
  <person role="bugowner" userid="m4r3k" />
<!– remove this block to publish your packages on the mirrors –>
  <publish>
    <disable />
  </publish>
  <build>
    <enable />
  </build>
  <debuginfo>
    <disable />
  </debuginfo>
<!– remove this comment to enable one or more build targets
  <repository name="openSUSE_Factory">
    <path project="openSUSE:Factory" repository="standard" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
 <repository name="openSUSE_10.2">
    <path project="openSUSE:10.2" repository="standard"/>
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
  <repository name="SUSE_Linux_10.1">
    <path project="SUSE:SL-10.1" repository="standard" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
  <repository name="SUSE_Linux_10.0">
    <path project="SUSE:SL-10.0" repository="standard" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
  <repository name="Fedora_7">
    <path project="Fedora:7" repository="standard" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
  <repository name="SLE_10">
    <path project="SUSE:SLE-10:SDK" repository="standard" />
    <arch>x86_64</arch>
    <arch>i586</arch>
  </repository>
–>
</project>

Pak pozměníme část <publish> z <disable /> na <enable />, čímž zajistíme vytvoření veřejně přístupného repozitáře, a dále si vybereme architektury a distribuce, pro které chceme balíčky sestavovat. Pokud je naše cílová platforma v zakomentované části XML souboru, tak máme vyhráno a tu část, kterou chceme, odkomentujeme. Ke komentářům se zde používají klasické XML komentářové znaky <!– a –>. V případě, že naše cílová platforma v nabídce není, tak ji prostě přidáme (nezakomentovanou). Můžeme ji přidat jak prostřednictvím editace XML souboru, tak prostřednictvím webového rozhraní, jak jsme si to popsali v druhém dílu seriálu. Nezapomeňte také vyplnit položky <title> a <description> něčím více popisným :-).

Nyní, když máme projekt vytvořen, je vhodné si stáhnout jeho obsah (stejně je zatím skoro prázdný) na lokální disk. To uděláme opět pomocí příkazu osc co home:m4r3k:kernel-backport. Následně pomocí příkazu osc linkpac nalinkujeme balíčky ze zdrojového projektu do projektu cílového (tím je v našem případě home:m4r3k:kernel-backport. V případě backportování kernelu stačí spustit následující bash skript.

for i in apparmor-parser device-mapper kernel-default kernel-source kernel-xen lvm2 openais udev apparmor-profiles kernel-debug kernel-docs kernel-syms linux-kernel-headers mkinitrd sysfsutils; do
	osc linkpac openSUSE:Factory $i home:m4r3k:kernel-backport
done

Po doběhnutí tohoto krátkého skriptíku a vybuildění balíčků bude k dispozici FTP adresář home:m4r3k:kernel-backport, v němž jsou jednotlivé repozitáře, pro které jste si nechali backportovaný balíček sestavit. Zde bych si dovolil požádat přítomné čtenáře, aby si v případě potřeby nevytvářeli vlastní backport openSUSE jádra pro distribuce openSUSE 10.2, 10.3 a 11.0 z openSUSE Factory, protože tento backport je v mém projektu home:m4r3k:kernel-backport a jednalo by se tak o zbytečné plýtvání prostředky buildservicu. Ale pokud máte zájem o backport nějakého jiného balíčku, tak neváhejte :-).

Balíčky si do systému můžete nainstalovat například touto posloupností příkazů (otestováno na openSUSE 10.3):

zypper ar --repo http://download.opensuse.org/repositories/home:/m4r3k:/kernel-backport/openSUSE_10.3/home:m4r3k:kernel-backport.repo
zypper up -t package

kterou si přizpůsobíte vlastním podmínkám. Například změna URL k *.repo souboru.

Patchuji, patchuješ, patchujeme

Pokud jste nahlásili bug a broukobijci vás zásobují patchi k otestování nebo si chcete do nějakého balíčku přidat patch, který doplňuje pro vás zajímavou funkci, a nebo si jen chcete balíček přeložit s trošku jinými volbami, buildservice má pro vás jednoduché a elegantní řešení. Opět se jedná o magii spojenou s příkazem osc linkpac jako v předchozím případě.

Pokud chcete přidat do balíčku nějaký patch, lze to provést pomocí editace souboru _link, který je v adresáři nalinkovaného balíčku po stažení pomocí příkazu osc co. _link soubor obsahuje něco podobného tomuto:

<link project="openSUSE:Factory" package="apparmor-parser">
<patches>
  <!– <apply name="patch" /> –>
  <!– <topadd>%define build_with_feature_x 1</topadd> –>
</patches>
</link>

Jak vidíte, soubor obsahuje zakomentované části <apply name="patch" /> a <topadd>%define build_with_feature_x 1</topadd>. Neobsahuje však jednu stejně důležitou část <add name="somepatch" after="3" popt="1" dir=""/>. Tento element add umožňuje přidat k nalinkovanému balíčku libovolný patch. Například pokud chceme vytvořit balíček opatchovaný patchem cool-feature.patch pomocí makra %patch -p2 tak upravíme _link do následující podoby:

<link project="openSUSE:Factory" package="apparmor-parser">
<patches>
  <add name="cool-feature.patch" popt="2"/>
</patches>
</link>

Výsledek úprav musíte v případě, že jste editovali lokální soubor, poslat na server pomocí příkazu osc commit. Pomocí tohoto řešení však můžete přidat jen nějaký patch na samotný tarball se zdrojáky. Co dělat v případě, že chcete upravit daný spec soubor? K tomu zase slouží <apply name="patch" />. Jeho použití si ukážeme třeba na situaci, kdy chceme openSUSE distribuční jádro poupravit tak, aby neobsahovalo App Armor.

Ze všeho nejdříve si stáhneme původní balíček kernel-default z patřičného projektu (záleží na verzi distribuce, pro kterou tuto změnu budeme provádět). Já použiji jádro z projektu openSUSE:Factory a zneužiji již založený projekt home:m4r3k:kernel-backport.

osc co openSUSE:Factory kernel-default
cd openSUSE:Factory/kernel-default
cp kernel-default.spec kernel-default.spec.orig

Nyní si najdeme v souboru kernel-default.spec řádek 174 s následujícím obsahem: Source110: patches.apparmor.tar.bz2 a pomocí znaku # provedeme zakomentování. Totéž uděláme i s řádkem číslo 192, který obsahuje NoSource: 110. Ještě musíme na řádku číslo 228 odebrat příkaz na rozbalení Source balíčku s číslem 110, což provedeme odstraněním části -a 110. Vzhledem k tomu, že k opatchování se používá soubor %_sourcedir/series.conf, který obsahuje seznam aplikovaných patchů, tak ještě musíme všechny patche týkající se app.armor odstranit, což můžeme udělat nějakým kódem v Bashi (viz můj diff). Následně soubor uložíme a pomocí příkazu diff -u kernel-default.spec.old kernel-default.spec si vytvoříme patřičný patch. Ten by měl vypadat nějak takto (samozřejmě si můžete výstup přesměrovat přímo do nějakého souboru):

--- kernel-default.spec.old     2008-06-27 14:23:46.936011735 +0200
+++ kernel-default.spec 2008-06-27 22:03:03.060007138 +0200
@@ -171,7 +171,7 @@
 Source107:      patches.xen.tar.bz2
 Source108:      patches.addon.tar.bz2
 Source109:      patches.kernel.org.tar.bz2
-Source110:      patches.apparmor.tar.bz2
+#Source110:      patches.apparmor.tar.bz2
 Source111:      patches.rt.tar.bz2
 Source120:      kabi.tar.bz2
 %define my_builddir %_builddir/%{name}-%{version}
@@ -189,7 +189,7 @@
 NoSource:       107
 NoSource:       108
 NoSource:       109
-NoSource:       110
+#NoSource:       110
 NoSource:       111
 NoSource:       120
 # The following KMPs have been integrated into the kernel package.
@@ -225,7 +225,7 @@
 fi
 echo "Architecture symbol(s):" %symbols
 # Unpack all sources and patches
-%setup -q -c -T -a 0 -a 100 -a 101 -a 102 -a 103 -a 104 -a 105 -a 106 -a 107 -a 108 -a 109 -a 110 -a 111 -a 120
+%setup -q -c -T -a 0 -a 100 -a 101 -a 102 -a 103 -a 104 -a 105 -a 106 -a 107 -a 108 -a 109 -a 111 -a 120
 # Generate the list of supported modules
 (   %_sourcedir/guards %symbols < %_sourcedir/supported.conf
     for how in external; do
@@ -253,6 +253,8 @@
 subarch=${1%/*}
 # Apply the patches needed for this architecture.
 %if ! %build_vanilla
+grep -v "patches.apparmor" %_sourcedir/series.conf > %_sourcedir/series.conf.tmp
+mv %_sourcedir/series.conf.tmp %_sourcedir/series.conf
 for patch in $(%_sourcedir/guards %symbols < %_sourcedir/series.conf); do
     if ! patch -s -E -p1 --no-backup-if-mismatch -i ../$patch; then
        echo "*** Patch $patch failed ***"

UPOZORNĚNÍ: Správně byste měli ještě opravit část %changelog a přidat tam nějaký záznam o tom, že se jedná o opatchovaný build - ale pro naše cvičné účely to není třeba.

Poté přejdeme do projektu (a patřičného adresáře), kde máme již nalinkovaný balíček kernel-default (v mém případě se jedná o adresář home:m4r3k:kernel-backport/kernel-default) a tento patch soubor do daného adresáře uložíme třeba pod názvem app_armor_remove.patch. Nyní editujeme soubor _link, abychom dostali podobný výsledek.

<link project="openSUSE:Factory" package="kernel-default">
<patches>
  <apply name="app_armor_remove.patch" />
</patches>
</link>

Ještě je potřeba to všechno poslat na server; to můžeme udělat třeba následující sekvencí příkazů:

osc add app_armor_remove.patch # přidá soubor app_armor_remove.patch mezi BuildServicem spravované soubory
osc commit # odešle změny na server

A k čemu mi to je?

Pokud jste poctivě četli druhý díl seriálu, tak jistě víte, že místo tohoto řešení můžete prostě do adresáře s _link souborem přidat soubor se stejným názvem, který nahradí ten původní. Důvod pro použití patchování v rámci _link souboru je však jednoduchý (kdo na něj přijde před jeho přečtením, má u mě bonbón :-)), tohle řešení je, na rozdíl od toho prvního, vhodné i do budoucna. Musíme si uvědomit, že když přeplácneme patřičný .spec soubor, tak v případě aktualizace dojde k nepříjemné situaci, kdy se nám balíček přestane aktualizovat automaticky s upstream projektem, jež linkujeme. Toto řešení je do jisté míry (limity příkazu patch, který si s každou situací nemusí poradit) dopředné, a proto, pokud dojde k prostému navýšení verze, to naše metoda s patchováním ustojí a sestaví novější verzi balíčku s potřebnými změnami, které jsme provedli.

Seriál openSUSE Build Service (dílů: 5)

První díl: openSUSE Build Service (OBS) aneb jak ho sbalit, poslední díl: Lokální Buildservice (OBS) – sestavujte vlastní balíčky.
Předchozí díl: openSUSE Build Service (OBS) - 2
Následující díl: openSUSE buildservice - 4 (spolupráce s upstreamem)

Diskuse k tomuto článku

[David Šmíd]

openSUSE (a pokud vím i všechny ostatní RPM-based distribuce) fungují na principu stabilních vydání, a ne na principu rolling-updates, jako je tomu třeba v případě Gentoo.

Minimálně jedna RPM-based distribuce (PCLinuxOS) funguje na principu rolling-updates.

[Käyttäjä 11133]

Aha, díky za info.

[Ilfirin]

Ovšem ten není v BuildService podporován, pokud se dobře dívám.

[Käyttäjä 11133]

No a?

[Ilfirin]

comment, nic víc.

[Käyttäjä 11133]

Aha, já myslel, že to má nějaký smysl, který mi uniká.

[phero]

podporovat bleeding edge distro ani neni mozny

[Käyttäjä 11133]

Je možné ho podporovat stejně jako openSUSE:Factory... Jen je to technicky náročné... (hlavně na HW)