Názory k článku apkg: nový nástroj pro automatizaci upstream balení

Ach, tak čeština. Že ten článek je zjevně překlad anglického originálu mi nevadí. Ale překladatel zůstal napůl v angličtině a třeba u "distro adresáře" (proč jen se mi v hlavě vybaví "vítězství Pyrrhy"?) jsem musel sáhnout po originále, češtinu jsem nebyl schopný rozparsovat.

Ale apkg vypadá zajímavě. Píšu na seznam věcí, co by se mohly hodit.

Mé veškeré znalosti v oboru jsou v angličtině a psát o nich v češtině bylo vyčerpávající.

Doufal jsem že zkušení uživatelé češtiny prominou mé anglicismy, netušil jsem že je to tak katastrofální že už článek nelze rozparsovat, tedy díky za info.

Autoritativní zdroj informací je apkg dokumentace, doufám že alespoň tam u čtení uživatelé tak netrpí ;)

Vypadá to zajímavě. Akorát mi není jasné podporuje-li to (už) openSUSE. V jedné fázi se mluví o Fedoře a podobných (respektive, že to mám nainstalovat na Fedoře a odvozeninách), ale openSUSE je vypsán v seznamu podporovaných RPM formátů. Tož jak to tedy je?
Pak mi není jasné, jak to funguje při výrobě RPM balíčků. Vygeneruje si to spec soubor a použije standardní RPM nástroje, anebo si to udělá nějak po svém?
Také se nutně vrací myšlenka, že popisy https://build.opensuse.org/ také hlásají, jak je to úžasné, dělá to balíčky pro různé distribuce (nejen pro openSUSE), hlídá to spoustu věcí, automaticky to vyrobí nový balíček vyjde-li nová verze nějaké závislosti atd atd., nicméně při výrobě spec souboru si člověk mnohdy užije spoustu legrace. :-)
A tím se dostáváme k poslednímu bodu. Jak to pozná potřebné závislosti? A jak to pozná, co všechno se má během instalace udělat? Míněno zdali to má použít jen make a někam něco nakopírovat, anebo make install a tak?

openSUSE je podporované v rámci rpm stylu, ač s ním bylo jako obvykle víc práce než bych si představoval.

Při výrobě RPM balíků apkg vyrenderuje .spec ze šablony (obvykle distro/pkg/rpm) a použije standardní nástroje, tzn. rpmbuild. Experimentálně podporuje i izolovaný build přes mock, ale to není dobře otestované.

OBS využíváme hojně a na papíře zní skvěle, v praxi je však celá řada problémů. apkg poslouží i těm co si chcou udělat vlasní ;) Zábava se .spec soubory nicméně neodpadne, jen je rychlejší doba iterace jelikož problémy s apkg lze jednoduše reprodukovat a debugovat lokálně.

Závislosti apkg parsuje přímo z balících šablon (tzn. v případě RPM ze .spec souboru). Co se má stát při instalaci je taktéž popsáno v balících šablonách. Zjednodušeně řečeno ty stejné soubory ve kterých je to popsané obvykle. apkg vesměs poskytuje jen lepidlo mezi existujícími nástroji, žádná nově vynalezená kola. Tedy doufám.

Děkuji za vysvětlení. Když už člověk používá OBS, tak se mi nezdá, že by to byl zásadní přínos, respektive asi by v praxi záleželo, s čím bude méně práce se spec souborem. :-) Asi to výhledově budu muset vyzkoušet.

Ještě mi trochu uniká zdali to nějak pomáhá při balíčkování pro různé distribuce. Jestli když mám spec pro openSUSE, tak zdali jej mohu (jednoduše) zrecyklovat pro jiná RPM nebo i DEB distra?

Když už člověk používá OBS, není apkg tak velký přínos, ale stále poskytuje určité výhody. Například když něco selže v OBS, je jednoduší to s apkg reprodukovat/de­bugovat a balení lze zahrnout i do systémů mimo OBS, např vlatní CI v kontejnerech apod.

Pro zajímavost se můžete podívat na skript Knot Resolveru make-obs.sh, který vytváří OBS zdrojové soubory pomocí apkg.

Při balení pro různá distra pomáha apkg právě v jednodušší recyklaci zdrojových souborů balíků a jednotným procesem. Obvykle se staví balíky pro všechna RPM distra z jedné šablony a pro všechny DEB z jedné šablony. Odlišnosti mezi jednotlivými verzemi lze pořešit Jinja šablonováním ve zdrojácích (např. {% if distro.match('u­buntu <= 16.04') %}) a nebo mít samostatné šablony pro distra co se příliš liší (např. distro/pkg/ubuntu-16.04). Tyto přístupy lze kombinovat.

Síla OBS je hlavně v tom, že build probíhá v (relativně) jasně definovaném prostředí. U jednoduchých projektů s minimem závislostí je to celkem jedno, ale u těch složitějších je běžné, že výsledek dost silně závisí na tom, co máte v systému nainstalované (a co ne). Nejde jen o to, že configure nebo cmake skripty detekují přítomnost knihoven a podle toho automaticky zapínají nebo vypínají volitelné featury, ale i o to, že u některých projektů dopadne build jinak a nebo dokonce úplně selže, pokud už daný software je nainstalovaný nebo dokonce běží. I verze knihoven hrají často roli, takže v současné době binárky přeložené proti openSUSE Tumbleweed nejdou použít na openSUSE Leap 15.2 nebo 15.3 kvůli nekompatibilním závislostem v glibc. Tohle všechno OBS řeší, takže u dobře udělaného zdrojového balíčku můžu (i lokálně pomocí " osc build") vyrobit RPM pro cokoli od SLES10 SP3 po Tumbleweed. (V praxi maintaineři distribuce tlačí na to, aby se specfiles univerzálně nepsaly, ale to je jiný problém.)

Vypadá to na výborný nástroj. Díky moc. Rozhodně vyzkouším.

Díky! Záměr je od začátku postavit robustní univerzální nástroj, který dělá v souladu s unixovou filosofií jednu věc dobře (balíky ze zdrojů) aby ji už nemusel každý projekt řešit sám skripty a převynalézat u toho kolo.

Pokud narazíte na něco, co by mohlo být lepší, dejte vědět a já to rád napravím. Dobrý uživatelský zážitek je na 1. místě