Hlavní navigace

Vlákno názorů k článku apkg: nový nástroj pro automatizaci upstream balení od Nuphar - Vypadá to zajímavě. Akorát mi není jasné podporuje-li...

  • Článek je starý, nové názory již nelze přidávat.
  • 4. 12. 2021 17:30

    Nuphar

    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?

  • 6. 12. 2021 14:46

    Jakub Ružička

    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.

  • 6. 12. 2021 17:52

    Nuphar

    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?

  • 8. 12. 2021 11:27

    Jakub Ružička

    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.

  • 8. 12. 2021 15:53

    Michal Kubeček

    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.)