Generování Flatpaků z RPM balíčků

Na stránkách české komunity Fedory vyšel zajímavý článek o tom, jak se generují flatpakové balíčky z již existujících balíčků RPM.

9.12.2019 12:33 | KOLEGA | Zajímavý článek

Komentáře

[Conscript89]

Takovy novy alien [1]? Otazkou je, proc ho nerozsirili, nebo to autora ani nenapadlo ze takova vec kdy existovala?
[1] https://en.wikipedia.org/wiki/Alien_(file_converter)

[Conscript89]

Myslim tim samozrejme autora toho noveho toolu, ne zpravicky.

[KOLEGA]

No to uplne ne. Nejde jenom o prekopani formatu, Flatpak se jeste trochu lisi strukturou a logikou. Defacto jde o "automaticke spousteni RPM v kontejneru" hodne zjednodusene.

[Conscript89]

Ok, to je pravda, to s alien ani moc nedava smysl vzhledem k tomu ze flatpak neni vlastne pro zadnou distribuci nativni podobne jako java aplikace (z principu) nejsou nativni pro zadny OS ale pro java runtime environment.

[Dojts]

No a teda Flatpack je teda statickej, co si "nataha" vse s sebou, nebo je to jeste nejak jinak?

Javu bych sem asi uplne netahal, to je asi o level jinde. Nicmene FP bych spis hodil do pytle se Snapem a trooosku Appimagem. A za me dobre pociny, skoda ze nebyly uz na zacatku milenia.

[KOLEGA]

Jmenuje se to Flatpak :D (taky jsem s tim mel problem).

Jinak napul, jsou jeste tzv. runtimy, coz jsou spolecne knihovny (treba GTK runtime, KDE runtime, FreeDestkop runtime ...)

Rozdil proti AppImage je treba v tom, ze AppImage primarne resi(l) problem s multiplatformnosti a az pak s bezpecnostni, kdezto Flatpak pocita se sandboxama od zacatku (a to chces, vzhledem k tomu, ze te to nuti verit vyvojari, ze je 1) slusnej a za 2) nebali ti tam CVE)

Nejprimejsi konkurence je Snap, kterej Canonical puvodne vyvinul pro mensi systemy a postupne se rozsiril na desktop. Ale tady vidim nekolik zasadnich ale. CENTRALIZOVANY system distribuce, jediny snap store, ktery ridi Canonical (+ je navic closed source) a prakticka nemoznost vice zdroju aplikaci.

Pro pobaveni je v teto diskuzi hlaska typu "Otevreni (jakoze open source) snap storu uzivatelum nic neprinese". https://forum.snapcraft.io/t/external-repositories/1760/100

[k3dAR]

nezkoumal sem, ale neni centralizovany store pro Snap v rukach Canonicalu vyhoda oproti https://www.abclinuxu.cz/zpravicky/flatpak-bezpecnostni-nocni-mura?

[Petr Ježek]

Takový způsob tvorby flatpakových balíčků z RPM mj. znamená, že tu mále konverzní utilitu pro balení jiných než RPM balíčků. Bylo by zajímavé srovnat třeba balíčkovací nástroje Archu při práci se zdoji pro RPM (v RPM) a s flatpakem. Jde o hledání cest k bezproblémové univerzalitě balíčků.

[petr_p]

Realisticky viděno konverzní nástroj je jen nástroj, který si občas vyláme zuby na existujících RPM balíčcích. V článku to takticky není vysvětleno, ale při té konverzi se neberou existující binární RPM balíky. Ve skutečnosti se berou zdrojové RPM balíky, ty se znovu překompilují a tyto nové binární balíky se pak instalují dovnitř flatpacku.

A problém je právě ta překompilace. Ona to totiž není obyčejná kompilace, ale mění se při ní nastavení prostředí RPM. Konkrétně se mění umístění souborů z prefixu / na /app. A to ne vždy funguje. Mohlo by se zdát, že je to pár chybně napsaných SPEC souborů. Jenže realita je tragičtější.

Některé balíky mají své soubory přesunout a jiné ne. To vnáší do balení vnitřní rozpor, protože najednou máte soubory dvou kategorií. A umístění souborů tvoří ABI a prosakuje do závislostí mezi RPM balíky. Takže pak vznikají neřešitelná dilemata, který soubor má patřit do které kategorie. V čemž nejen že není jasno, ale v podstatě je to ekvivalentní problém softwarových kolekcí (taktéž technologie pro přemístění souborů v RPM balících), kteréžto byly z důvodu zahnojení SPEC souborů ve Fedoře zakázány a ve světě RHELu jsou kolekce nad kolekcemi (o což se snaží flatpacky) věc čistě teoretická, protože prakticky trpí stejným problémem.

Že něco není v pořádku, ukazuje fakt, že problém dělení souborů do svou kategorií se nepodařilo za celý rok vyřešit.