Balíčky pro všechny distribuce snadno a rychle aneb vyzkoušejte openSUSE Build Service

Když Novell oznámil otevření vývoje SUSE Linuxu, komunita zajásala a oblíbenost nového openSUSE se rychla začala šplhat do závratných výšin, kde si dosud hovělo pouze poněkud opuštěné Ubuntu. Pro většinu uživatel openSUSE jeho otevřenost znamená jen to, že mohou osobně otestovat všechny alpha i beta verze a hlásit na ně chyby: to je velmi příjemné jak pro ně, tak pro SUSE - je daleko jednodušší opravit chybu včas než posléze vyrábět opravy pro vydané produkty. Možností, jak se zapojit do vývoje openSUSE je však víc. Tento projekt má pro někoho možná překvapivě co nabídnout i uživatelům jiných distribucí.

Jednou z nejdůležitějších součástí projektu openSUSE je Build Service - zjednodušeně řečeno místo, kam nahrajete své zdrojové kódy a spec soubory, a ven vám vypadnou balíčky pro nejrůznější distribuce i architektury. Kromě spousty verzí SUSE Linuxu a openSUSE podporuje Build Service i mnoho dalších distribucí, jmenovitě například Ubuntu a Fedoru - pokud je mi známo, další buildsystém, který by uměl něco takového, neexistuje. Mezi podporované architektury patří i386, x86_64, s390, s390x, ia64, ppc a ppc64. Ptáte se, k čemu vám to může být dobré? Pokud jste vývojář nějakého open source projektu, který dosud nemá své místo v běžných linuxových distribucích (nebo má, ale distribuční maintainer balí váš software podivně a není s nám rozumná řeč), možná si přejete obdařit své uživatele balíčky pro jejich distribuce. Podporovat milion distribucí ve všech možných verzích a na spoustě architektur samozřejmě není v silách normálního člověka, kromě jiného proto, že většina lidí neskladuje ve sklepě mainframe. S Build Servicem to ale bude docela jednoduché.

Pokud jste uživatelem openSUSE a máte alespoň nějaké znalosti programování (hodí se umět aspoň trošku psát v shellu a mít dost trpělivosti při čtení dokumentace o RPM), můžete mít pocit, že distribuce nevypadá přesně tak, jak byste si přáli. Možná nějaký program chybí, možná je zkompilován tak, že nevyhovuje vašim potřebám... potom není nic lepšího než založit si na Build Service nový projekt, vytvořit balíček, a ten pak prostřednictvím repozitářů na software.opensuse.org nabízet všem ostatním (tady je návod, jak si přidat repozitář do YaSTu). Bude se vám hodit nějaká dokumentace: základní čtení představuje oblíbené RPM HowTo, na abclinuxu.cz vyšel také vynikající seriál Rukověť baliče RPM od Yetiho v češtině. Až budete mít nějaké ponětí o RPM samotném, možná vás bude zajímat, jak se dělají balíčky v SUSE: potom se zkuste prokousat dokumentem SUSE Package Conventions. Dozvíte se v něm, co všechno by měl dobrý susí balíček splňovat (důležité je například psát init skripty v souladu s Linux Standard Base a dodržovat Filesystem Hierarchy Standard), a jak se používají nástroje pro SUSE specifické: sem patří například nejrůznější užitečná RPM makra či informace o sysconfigu. Mimochodem, já ten dokument teď spravuju, takže prosím o hlášení chyb a nesrovnalostí, případně i námětů na zlepšení.

Pokud v Build Service spravujete balíček, který je spravován i v SUSE, je rozumný nápad upozornit na něj správce oficiálního susího balíčku: kontakt na něj asi nejjednodušeji získáte, když se v changelogu podíváte, kdo se v něm naposledy přehraboval. Jednak má smysl práci na balíku synchronizovat, jednak víc hlav víc ví a výsledkem by tedy měl být lepší balíček. Susí správce vám pravděpodobně ukáže, jak dělat RPM, aby to nebyla čuňačina (což se napoprvé zdaří téměř každému), vy mu naopak můžete předat své zkušenosti s používáním balíku a třeba věnovat pár pěkných patchů. Susí balíkáři mnohdy počítají své balíčky na stovky, tudíž je všechny neznají zevnitř dobře tak, jak je můžete znát vy.

Jak by to celé mohlo proběhnout? Například řekněme, že používáte zálohovací program bacula. Potřebujete ho mít zkompilovaný s podporou PostgreSQL, ale susí balíček chodí jen s MySQL. Zaskřípete zuby, proklejete správce balíku do devátého kolena, stáhnete si zdrojové RPM, založíte projekt na Build Service a začnete hackovat balíček. Za pár hodin, dnů nebo týdnů (zcela dle vašich schopností) se vám podaří najít čistý způsob, jak vyrobit balík s podporou všech databází. Zaradujete se, podíváte se do changelogu a zjistíte, že v suse se o balíček stará nějaká anicka@suse.cz. Povíte jí o svém projektu, a ona vám ho buď hodí na hlavu (šeredné hacky snadno a rychle by zvládla taky) a nebo naopak vaše modifikace převezme do distribuce a v changelogu vás vychválí o nebes, protože sama zatím, topíc se v jezeře bugů, nenašla čas udělat to pořádně.

Jak celý Build Service funguje je pěkně popsáno na openSUSE wiki - bohužel zatím jen anglicky, takže kdyby se našel dobrovolník, který má pár volných chvilek, ochotný přeložit tu stránku do češtiny, jistě by na něj dopadl alespoň odlesk nehynoucí slávy. Build Service nabízí webové rozhraní (kdo umí anglicky, tomu se jeho použití vysvětluje téměř samo), CLI nástroj s ovládáním podobným SVN a stabilní API umožňující napsat si frontend podle vlastní chuti. Když se zaregistrujete (pokud vím, měl by vám stačit jeden účet pro Build Service, openSUSE wiki i bugzillu) a přihlásíte, získáte tím svůj první projekt home:/username a v něm si můžete hrát a testovat dle libosti. (Jak funguje hierarchické uspořádání projektů v BS, a jak se celé webové rozhraní ovládá, odhalíte velmi rychle. Když ne, začtěte se do wiki. Můžete také zavolat o pomoc do opensuse-buildservice mailing listu a nebo na IRC: tady jsou kontakty. V neposlední řadě se můžete zeptat třeba mě, nebo kteréhokoliv svého oblíbeného člena českého balíkářského týmu. Ke kterému se mimochodem, kdyby vás to začalo bavit, můžete i přidat.)

Abych celou dobu jenom nechválila: Build Service je projekt velmi mladý (začal vznikat v době, kdy vyšel SL 10.0) a jako takový občas stále nefunguje na sto procent. Naštěstí to obvykle není na překážku v jeho používání, navíc na něm pracuje velký tým a chyby neustále loví: nebojte se Bugzilly. Většina Build Service je open source (hostovaný na Novell Forge), takže jej můžete radostně hackovat i vy. (V blízké budoucnosti bude uvolněn kompletně, a pak vám nebude nic bránit v tom, abyste si jej rozjeli i doma: snad jen to, že zřejmě nemáte ve sklepě ten mainframe, a tak nebude schopni podporovat tolik architektur jako my.)

Happy hacking...