Jak vypadá build-stroj Peťošova repozitáře

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
BuildKomp, na kterém je položený router a vedle černý externí 40GiB 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 displaye, byl nakonec poškozen i přenosový datový kabel
Prasklé víko displaje, byl nakonec poškozen i přenosový datový kabel a display už hold nefunguje

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 nahoru na tlačítko Mandriva Linux 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í.

1 komentář u „Jak vypadá build-stroj Peťošova repozitáře“

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *