Jak vyrabet gentoo ebuildy...

5.3.2009 18:24 | Přečteno: 1407× | Gentoo | | poslední úprava: 5.3.2009 18:22

Tento malý článeček si klade za cíl seznámit čtenáře s postupy a procesy, které máme v Gentoo pro začleňování věcí do repozitářů (ať se jedná o hlavní strom, či libovolný overlay - na tom nesejde).

Průběh začleňování budu popisovat na balíku sci-misc/boinc a postupy specifické pro KDE ebuildy budu ukazovat pomocí balíku kde-misc/krusader.

1) QA

Prvním krokem bude kontrola, zda jsou splněny všechny formality pro daný ebuild. (Nejefektnější je začínat ebuild ze souboru skel.ebuild se smazanými komentáři, nebo ještě lépe použít vim (nebo emacs no...), který při editaci automaticky vyplní vše potřebné výchozími hodnotami).

Vizuální kontrola

Při procházení ebuildu si všimneme nejprve hlavičky. Ta je formálně daná a nemění se.

Po ní následuje dobrovolná definice EAPI, zde v obou případech používáme EAPI=2. Dále by měly být uvedeny povinné proměnné, oddělené podle typu, jak je možno vidět u boincu. Jistě si všimnete, že u krusaderu mám chybu (licence správně patří až do druhého bloku).

Nejdůležitějším kritériem při vizuální kontrole je pouze čitelnost a také to, zda obdobně vypadají ostatní ebuildy od dané herd.

Po vizuální stránce jsou tedy oba ebuildy naprosto v pořádku. Nyní je třeba přistoupit ke kontrole jejich správnosti.

Kontrola dat

Ebuild máme v lokálním overlay. Jeho kontrolu provedeme velice snadno příkazem:

$ cd /path/to/the/ebuild/dir/ && repoman full

Tento nám vrátí nějaký výstup. Vždy nám prozradí, co je špatně a naším finálním cílem je, aby si repoman vůbec nestěžoval.

Jak můžeme vyzkoušet u krusaderu a u boincu, u obou si stěžuje na chyby.

sci-misc/boinc:

  ebuild.allmasked              1
     sci-misc/boinc
  upstream.workaround           1
     sci-misc/boinc/boinc-6.4.5.ebuild: Upstream parallel compilation bug (ebuild calls emake -j1 on line: 96)

První chyba říká, že nemáme žádnou stable verzi daného balíku. To nás opravdu nebere a tedy taková chyba nám nevadí.

Druhá chyba se zaobírá zajímavější věcí a to jest chybou paralelního make. Určuje nám, že daný program se neumí zkompilovat ve více vláknech. Což je definitivně chyba upstreamu a měla by se nahlásit. Přesto "emake -j1" je dostatečný workaround, dokud to upstream nevyřeší.

kde-misc/krusader:

  RDEPEND.implicit              1
     kde-misc/krusader/krusader-2.0.0_beta2-r1.ebuild: RDEPEND is not explicitly assigned

Tato chyba má velice zajímavé pozadí. Protože jsme my, Gentoo vývojáři, cháska hádavá, nemohli jsme se více než pár let dohodnout, jestli implicitně deklarovat RDEPEND="${DEPEND}". Nakonec - před pár týdny (prostředek ledna 2k9) - se rozhodlo, že RDEPEND musí být vždy definováno a repoman bude hlásit chybu v případě, že tomu tak nebude.

Nyní umíme zkontrolovat kvalitu ebuildu a dokážeme aspoň částečně odhadnout zda nám jej vývojáři přijmou a začlení.

Nezapomínejte, že efektivní je také uplacení nějakého vývojáře aby ebuild udělal. K tomu se hodí různé cukrovinky a nebo pivo. ;]

2) Píšeme ebuild

Obecně je opravdu nejdůležitější, aby ebuild splňoval všechny náležité požadavky (aby vypadal stejně jako ty vostatní od stejné herd hej ;]).

Pro KDE4 (cmake)

Úplně nejjednodušší je pro srovnání používat ebuildy, které máme v kde-testing. Většinu věcí za vás naše eclass udělá automaticky, jak je možno vidět na obsahu ebuildu pro krusader.

KDE4 eclass fungují principem, že se nadefinují hodnoty a potom se vygenerují požadované funkce, takže je třeba všechny definice provést před příkazem inherit.

Důležité proměnné:

KDE_LINGUAS obsahuje všechny locale, se kterými může daná aplikace spolupracovat. K této proměnné se přidružuje KDE_LINGUAS_DIR, což je adresář ve kterém se nacházejí .po soubory nebo podadresáře s názvy daných linguas.

KDE_MINIMAL určuje minimální verzi kde potřebnou pro běh aplikace, default (když nic nedefinujem) je 4.2.

Po inheritu následují definice nám již známých proměnných, u kterých nás nic nemůže překvapit, i když kde4 eclass automaticky využije přítomnost debug use flagu a umožní debug build pomocí cmake. Také proměnná htmlhandbook je kde specialitka a umožnuje tvorbu html dokumentace (tato bude brzo zrušena protože to budeme řešit jinak a radostněji).

Funkce src_prepare:

Zde můžeme vidět, že pomocí podmínek se rozhoduje, zda chceme dokumentaci či ne, jednoduchou úpravou souboru CMakeLists.txt.

Dále také odstraňuje verbose výstup, který je opravdu do nebe volající blbost, protože se díky němu aplikace kompilují 2-3x déle a nikomu jinému nežli autorům ty zprávy nic neřeknou.

Závěrem je třeba zavolat kde4-base_src_prepare. Každá funkce v ebuildu musí volat svou nadřazenou funkci z kde4-base nebo kde4-meta, v opačném případě skončíte, pokud máte štěstí, s nefunkčním ebuildem.

Funkce src_configure:

Zde nastavujeme kompilační parametry, pro krásnou ukázku doporučuji ebuild kde-base/kopete. Tyto parametry lze vždy najít v souborech CMakeLists.txt jako proměnné hodnoty OPTION (samozřejmě, že to může být napsané prasácky a ty hodnoty tam nebudou).

S využitím autotools

Ebuild pro boinc je rozhodně zajímavější a těžší pro údržbu. ;]

Nejprve se podíváme na tu hromadu závislostí. Většina z toho se dá zjistit jednoduchým pročtením README a ./configure --help, případně shlédnutím probíhajícího ./configure. Tyto skripty nám poví celkem rády všechny pro naši aplikaci potřebné náležitosti.

Funkce src_prepare:

Jak můžeme vidět, boinc nemá některé věci v pořádku, ty se snažíme uklidit. Moje lenost je nebetyčná a proto jsem ještě neodstranil QA warning ohledně prestripped binaries (což je něco, co by se vám rozhodně stávat nemělo, alespoň dokud nemůžete sami do stromu commitnout O:]).

Funkce src_configure:

Zde nastavujeme a předáváme všemožné proměnné econf skriptu.

Nejprve si nadefinujeme přidané cflags; toto by se nemělo dělat pokud k tomu neni setsakra dobrej důvod.

Pak nastavíme WXWIDGETS, což já třeba vůbec nevěděl, jak se dělá, tak sem si to ukradl z nějakého jiného ebuildu používajícího wxwidgets a upravil dle svých potřeb.

Dál nám následuje jednoduchý econf, u něj lze veškeré hodnoty zjistit pomocí ./configure --help.

Funkce src_compile:

Jediná věc, která se zde děje, je omezení počtu JOBS (paralelních procesů make) na 1 samotinký, což jistě nepotěší vlastníky vícejaderných CPU. :)

Funkce src_install:

Celkem jednoduchá instalace. Zde je důležité říct, že je potřeba opravdu velice bedlivě sledovat, co se vám kam instaluje a aby to nebylo mimo FHS (s tímto mají lidé nejvíce problémy).

Funkce pkg_setup:

Zde se provádí různá nastavení, která se nehodí nikam jinam, v našem případě nastavení uživatelského účtu a skupin.

Funkce pkg_postinst:

Tato funkce se v 99.99% případů používá na informace o balíku. Jak je vidět u boincu, musel jsem být velice, ale velice, ukecaný.

Vložení ebuildu do stromu/overlaye

Jak přesvědčit nějakého vývojáře, že zrovna náš ebuild je ten nejlepší nejgeniálnější a prostě celkově nej, je velice klíčová otázka. Hlavní kritéria jsme si prošli v první kapitole. Pokud splňujeme tyto, máme velice dobře našlápnuto k vítězství.

Jak takového vývojáře tedy kontaktovat. Máme dvě možnosti:

1. Vyplnit bug v bugzille a připojit náš ebuild jako attachment. Při použití tohoto postupu máme zaručeno, že to časem někdo udělá. Pokud to není úplně nová aplikace; v tom případě je dobrou volbou sunrise.
2. Použijeme irc ( http://www.gentoo.org/main/en/irc.xml ) Použití irc nám zaručuje ve většině případů celkem dobrou realtime komunikaci, a je tedy vyšší šance, že to někdo udělá rychle :) (ale taky nám někdo mnohem rychleji vyčte naše chyby :P)

Závěr

Pokud váš výtvor splní všechny, nebo alespoň valnou většinu, podmínky tak je celkem reálné, že bude do gentoo zařazen.

Hodně štěstí s tvorbou balíčků, a pište jich co nejvíc ať se nemusíme my vývojáři příliš namáhat :P

Jo a abych nezapomněl, rád bych poděkoval Tilye za to, že to po mě přečetla a vynadala mi za největší chyby :)

       

Komentáře

[Marián Kyral]

To použití irc znamená mít vytvořený bug report, nebo se dá i bez něj?

[Scarabeus IV]

Do sunrise jedine s nim, ale k ostatnim to nemusi bejt potreba.
Vetsinou pokud ho nemas a prijdes na irc tak ti reknou zda je potreba ci ne.

[Marián Kyral]

Díky, tak jsem vykradl jeden plasmoid v kde-testing a udělal dva nové ebuildy

http://bugs.gentoo.org/show_bug.cgi?id=261364 (system load viewer 0.6)

http://bugs.gentoo.org/show_bug.cgi?id=250803 (yaWP - Yet another weather plasmoid 0.2)

[Scarabeus IV]

Predano HT pro zacleneni. :D

[Marián Kyral]

Díky