Jak vypadá build stroj pro Mandriva Linux?

Můj repozitář, který existuje už dva roky (od verze 2009), jsem začal provozovat kvůli (tehdy) ne zrovna dobrému ovladači grafické karty Intel. Ten se tvůrci rozhodli přepsat zcela od začátku a jako každý projekt měl i nový ovladač Intel své počáteční problémy (konkrétně s tristním ne-výkonem). Od té doby jsem repozitář značně rozšířil a propracoval na úroveň, na které je repozitář nyní.

  • Velikost: 9.8 GiB
  • Celkový počet balíčků: 709

Rozhodl jsem se vás blíže seznámit s tím, jak celý repozitář spravuji a jak vzniká nový balíček.

Hardware

Prvně bych vám rád představil onen slavný build-komp. Jedná se o sedm let starý notebook od firmy Aušus, tehdy nejlevnější verze s bezdrátovou wifi, která byla tehdy na trhu. Konkrétní označení Asus A3H:

  • Procesor: 1.6 GHz Pentium M
  • Paměť: 1 GiB
  • Disk: 2×40 GiB (dva disky, jeden interní, druhý externí)

Průměrné vytížení procesoru tohoto stroje se pohybuje okolo devadesáti procent výkonu, snažím se jej šetřit, takže pokud nepřekládám, je počítač vypnutý.

BuildKomp, na kterém je položený router a vedle černý externí disk

U notebooku se vyskytlo několik problémů. Asi dva týdny poté, co skončila záruka (po dvou letech a dvou týdnech), prasklo víko. Ze začátku to byla jen malá prasklinka, která se časem se rozšířila. Asi po třech letech od koupi přestal fungovat displej, který je ve víku. Nefungující monitor mi vůbec nevadí, protože stejně se k počítači připojuji pouze přes SSH (terminál) a případně si grafiku přeposílám přes SSH k sobě na svůj pracovní počítač.

Prasklé víko displeje byl nakonec poškozen i přenosový datový kabel

Abych udělal fotku, kterou vidíte, otevřel jsem po roce monitor a (světe div se) pant se zcela rozpadl (a displej tam je pouze díky druhému pantu, který zatím drží).

Tímto si rozhodně nechci nijak stěžovat! Počítač přesto, že je staršího věku a ne zcela fit, co se šasi notebooku týče, funguje bezvadně.

Zatímco šasi notebooku mě netrápí, diskový prostor pomalu začíná. Připravil jsem velké množství linuxových počítačových her a bohužel datové soubory, jako jsou textury, mapy, zvuky a další, jsou již poměrně nekomprimovatelné a přitom samy dost velké (průměrná hra má asi 600 MB). Druhý problémový fakt je, že součástí repozitáře (oddělenou, nebojte) jsou i zdrojové RPM (tzv. SRC.RPM nebo SRPM), takže adresář obsahující RPM a SRPM soubory pro 2010 Spring má celkem 22 GiB. Není třeba velké matematiky, aby bylo zřejmé, že na 40 GiB disku bude velmi brzy velmi těsno (ono už je, protože spolu se staršími repozitáři je již disk z 96 % zaplněn).

Software

Nyní, když už víte, s čím zhruba pracuji, seznámím vás se softwarovými nástroji, pomocí kterých provádím RPM překlad. Věřte nebo ne, ale ten naprosto nejnepostradatelnější nástroj není ani tak nástroj pro překlad balíčků, ale prostý textový editor… Ačkoli… prostý… Používám nástroj Emacs — dokonalý operační systém, kterému chybí již jen dobrý textový editor. Ale vážně — Emacs je textový editor napsaný v jazyce LISP. Jako jeden z mála (ještě VIM a MCEdit) editorů totiž podporuje zvýraznění syntaxe v souborech SPEC.

Dalším nástrojem nutným pro build, je rpmbuild. Toto je opravdu nástroj zodpovědný za překlad a zabalení RPM balíčku. Krom těchto nástrojů používám systém iurt a mdvsys. Jedná se o sadu skriptů, které značně zvyšují kvalitu výsledných RPM balíčků tak, že jsou zaručeny správné závislosti (tj. mohu plně garantovat závislost na repozitáře main, contrib, nonfree a PLF-free a -nonfree a samozřejmě můj) a správně nastavené závislosti pro překlad.

Jak tedy funguje překlad balíčku? V několika krocích:

  1. Připravím řídící SPEC soubor, patche a zdrojové kódy pro program/balíček.
  2. Všechny změny nahraju do SVN — systému pro správu verzí a změn.
  3. Spouštím překlad přes iurt s parametrem pro test. Celý balíček se systém pokusí přeložit a případně mi vypíše chyby.
  4. Pomocí systému iurt s parametrem test ověřím přeložitelnost a správnost kroku 1. Pokud se objeví chyba, vracím se ke kroku 1 a celé kolečko se opakuje.
  5. Pokud test překladu proběhl v pořádku, mohu přistoupit k finálnímu spuštění překladu. Zde se na konci vytvoří balíček, nahraje se do lokálního repozitáře na místním disku, aktualizují se HDlisty (soubory s obsahem repozitáře).
  6. Provede se aktualizace nebo instalace balíčku. To záleží na tom, zdali byl balíček již nainstalován a nebo ne.
  7. Celý disk se synchronizuje s internetovým úložištěm.
  8. Vám se objeví červená ikonka, že jsou k dispozici aktualizace balíčku xyz.

Mnohem zajímavější ovšem (dle mého) je, co se skrývá pod tím tajemným „se přeloží“ případně „iurt přeloží“. Jedná se totiž o mnohem složitější operaci než jen rpmbuild -ba jmenobalicku.spec:

  1. Vytvoří se chroot adresář / s čistou instalací Mandriva Linuxu ve verzi 2010.2. V této minimální instalaci je pouze jádro, nástroje GNU a balíček task-c-devel, task-c++-devel nutné pro překlad a konečně rpm-build (jenž je zodpovědný za tvorbu RPM balíčku). Také se sem ze SVN překopírují zdrojový archiv, patche a SPEC soubor pro překládaný balíček (tedy použije se to, co je v databázi, nikoli to, co je připraveno na disku).
  2. V tomto novém root adresáři se spustí (pomocí chroot) nová instance Mandriva Linuxu.
  3. SPEC soubor se ověří příkazem rpmlint.
  4. Do této se nainstalují všechny závislosti pro překlad definované v řídícím SPEC souboru (tag BuildRequires:)
  5. Nyní je již vše připraveno pro překlad. Ten se spustí a dle příkazů uvedených ve SPEC souboru (neboli nyní se provede ono rpmbuild -ba xyz.spec).
  6. Při úspěšném překladu se vytvořené finální balíčky překopírují do patřičných adresářů.
  7. Chroot se deaktivuje a dočasný chroot adresář / se smaže.

Základní rozdíl mezi finálním překladem a „testovým“ tkví v databázi, ze které se v bodě 1 kopírují zdrojová data. Zatímco ostrý (finální) překlad používá skutečně data z databáze tak, jak je napsáno v bodě 1, tak testovací překlad překopíruje data (vč. SPEC souboru) z disku. A nakonec při testovacím překladu se výsledný balíček(/balíčky) smažou.

Budoucnost

Rozhodl jsem se, že se pokusím rozšířit svůj repozitář na 64bitový systém. To s sebou nese pořízení nového hardwaru a jeho následná konfigurace. Vzhledem k tomu, že nemám v tuto chvíli žádný počítač se 64bitovým procesorem, nechal jsem hardware na vás. K mému překvapení se objevilo hned několik nabídek a v tuto chvíli mám přislíbený celý počítač se vším potřebným, jen čekám, než jej dopravím z Prahy do Brna.

Vzhledem k SVN verzovacímu systému by se zas až tak neměla změnit práce, pouze bude nutné upravit konfiguraci build-systému tak, aby se iurt pokusil provést překlad nejen na jednom, ale na obou systémech (32bit i 64bit).

Doufám, že vás tato exkurze do překladu RPM balíčků aspoň trochu bavila a zaujala vás.

A kde je ten můj repozitář? Klikněte na adresu http://petos.cz/rpms, kde se nachází nejen návod na přidání repozitáře, ale také seznam všech balíčků, které se v repozitáři nacházejí.

10 komentářů

  1. fri | 04.04.2011 | 18:17 | Odpovědět

    Článek mě zaujal. Jestli si dobře vzpomínám, tak pouze vytváříš rpm balíčky. Někdy v minulosti jsi o tom možná takto psal, i když mám dojem, že se nebráníš ani drobným úpravám, pokud víš, jak je udělat, a víš jak na to.

    Někdy mě napadlo, že bych byl rád věděl, jak udělat rpm něčeho, co v Mandrivě nebylo, ale nezkoušel jsem to. Na podzim minulého roku jsem, když jsem dělal pokusy s Fedorou, předhodil jeden program s Pythonem Lukáši Zapletalovi, poněvadž něco jako nastavování Python Path, když to po mě chce příkazová řádka, bylo nad mé chápání (proč to nejede samo), ale i ten mi potvrdil, že by to bylo složité – program byl podle něho svým autorem udělán tak, že “zadrátovaný”, čímž myslel to, že autor při svém programování nemyslel na to, že existuje víc distribucí.

    Kdybych měl někde přesně a podrobně popsaný postup, jak dělat ten balíček, jak dělat ten SPEC soubor, jak …, mohl bych využít ten stroj, který jsem pořídil loni na podzim. Prostě jako pokus u těch normálních programů, které se běžně daří nainstalovat, a když to chce nějakou závislost (-devel, který ovšem Mandriva/mageia/Mája obsahuje), tak si to o něj jasně a srozumitelně řekne, a ne že se objevila chyba čehosi, co spíš souvisí s tím, jak to má distribuce s tím vším okolo.

    Teď co Mageia udělala základní kroky k oné bezproblémovosti, mohl bys popsat, pokud tomu rozumíš, jak velký krok k zbavení se problémů, pokud jsi na ně během balíčkování přišel, byly-li jaké, které se možná vyskytovaly předtím u Mandrivy, to je? Myslíš, že vytváření SPEC souboru bude s Mageiou jednodušší? Máš zájem na tom povzbuzovat i tvé příznivce k tomu, aby dělali balíčky – třeba manufakturně, abys je po vyzkoušení někam přidal, doporučil, nebo by si je inzerovali a hlídali, šířili sami?

    1. Peťoš Šafařík | 04.04.2011 | 18:34 | Odpovědět

      Asi takto: Lidé, kteří vyvíjeli Mandiva Linux vytvořili Mageiu včetně balíčků a dalších. Takže žádné zjednodušení nečekám, resp. to bude totéž.

      Informace čerpám z Maximum RPM: http://docs.redhat.com/docs/en-US/index.html

      > Máš zájem na tom povzbuzovat i tvé příznivce k tomu, aby dělali balíčky,…
      Ne. Už jsem to psal několikrát např. J. Šenkovi — na koleni zbastlené balíčky jsou pro uživatele nebezpečné.

  2. fri | 04.04.2011 | 20:01 | Odpovědět

    A Jakub Šenk už ví, jaké úrovně by musel dosáhnout, aby nedělal nedodělky? :?) Nebo si nedal říct.

    1. Peťoš Šafařík | 04.04.2011 | 20:09 | Odpovědět

      Jakub svůj repozitář s přechodem k Ubuntu uzavřel. A dokumentaci měl stejnou jako každý jiný (vč. mě). Stačilo jen hledat, číst a studovat. Základní zdroj informací jsem již napsal — kniha Maximum RPM.

  3. fri | 05.04.2011 | 19:09 | Odpovědět

    Fedora má, jak jsem si všiml, jakýsi systém, který umožňuje finančně podpořit tvůrce balíčků. V našich podmínkách bych byl, když by mi na něčem záleželo, finančně převodem podpořit tvůrce balíčků, který by byl na doporučeném seznamu, jen v rámci ČR naší měnou. To bych zvládl. Muselo by to být nabízeno na viditelném místě. 🙂 Zase by se od toho neočekávala nějaká masovost, ale příklad hodný následování. Kniha o Mandriva linuxu apod. nevyšla, a kdoví, jak to bude v budoucnu, ISO z internetu a tak podobně, tak by měla v kapsách některých podporovatelů zůstat nějaká tomu odpovídající částka. A lidé jsou altruističtí, že ano.

    Taky by se v takovém případě hodila obecná možnost diskuze k tomu, co by bylo vlastně smysluplné, aby se, kdyby to s sebou neslo větší nároky, mohlo spojit víc stejně smýšlejících, kteří by tímto něco podpořili, poněvadž by jim to přišlo smysluplnější, než studovat dokumentaci, a pak něco na koleně “bastlit”. Programů jsou mraky, ale některé jsou použitelnější (kolik programů totiž běžný člověk potřebuje k spokojené existenci, kromě … :-), a byly by přínosem – aby to měla i “naše značka”, když to mají u konkurence.

    1. Peťoš Šafařík | 05.04.2011 | 20:41 | Odpovědět

      no, nechtěl jsem to psát zrovna sem, ale můžeš podpořit jmenovitě Peťoše, čti více na stránce mého repozitáře (http://petos.cz/rpms). Někteří již tak učinili…

      Dále můžeš podporovat Liberix, který spravuje tyhle stránky (a mnohé další weby): http://liberix.cz/podporte-nas/financne/

      Něco “vyššího” není a pokud vím, neplánuje se.

      PS: používej tlačítko Odpovědět:, jinak tu je zmatek, vypadá to, že já reaguji na Tebe a ty na článek…

  4. Aminux | 08.04.2011 | 22:42 | Odpovědět

    Pěkný. Takže už se můžem těšit na 64 bit repozitář? A pokud jo, budeš předělávat stávající balíčky do 64 bit verze?

    1. Peťoš Šafařík | 08.04.2011 | 23:01 | Odpovědět

      Ano, 64bit repo bude, ale časově to vidím až od verze 2011. A zpětně rebuildit 2010.2 nebudu. Repozitář pak zmrazím tak, jak jsou v současné době zamraženy 2009, 2009.1 a 2010.0.

      1. Aminux | 08.04.2011 | 23:19 | Odpovědět

        Ale Dračí historii pro 2011 uděláš ne? Kdyžtak bych musel použít Dosbox 🙂

        1. Peťoš Šafařík | 08.04.2011 | 23:24 | Odpovědět

          jo tak… Ano, některé balíčky, které jsou nyní v repozitáři a nebudou v oficiálních, budou i v další verzi…

Leave a comment

Sorry, you must be logged in to post a comment. Login