Názory k článku
Navržen Toolpak: Flatpak pro nástroje

Někteří na toto používají (zneužívají) PyPI. Dávají tam sw, který s Pythonem už nemá nic společného. A wheel formát umí i různé platformy.
Zájem u něco takového určitě bude.

zadne pridavne zavislosti? Ok, a co je spatneho na deb a rpm? vytvorit tyhle balicky fakt neni komplikovane kdyz to nema zavislosti.

Tak oni závislosti mají, ale budou všechny v tom jediném Toolpaku. Tedy nebude to záviset na žádných jiných balíčcích jako rpm/deb a nevznikne tzv. dependency-hell.

Špatného na tom není nic.
Nicméně když používáte immutable distro tak nechcete do každého image dávat haldu toolů které použijete jednou za uherský rok.
Osobně, když jsem migroval z NIXu na ostree Fedoru jsem začal používat distrobox (které má poměrně dost úskalí), přešel plynule na brew ale je na něm tak nějak cítit že začínalo na Macu. Třeba toolpak bude řešení ;-)

Tohle není o vytváření, protože třeba zrovna Flatpak je z autorského hlediska děs a hrůza.

S rpm / deb je spousta problémů spíše z uživatelského hlediska:

- nelze instalovat jako uživatel, případně jen pro některé uživatele
- nelze oddělit verze aplikace od verze systému (představte si Debian stable na systém a unstable na aplikace)
- nelze více verzí nástroje zároveň

Co je na tom z autorského pohledu děs a hrůza? Roky spravuju několik aplikací na Flathubu, mám i vlastní repozitář, zapojení do CI... Celkově mně to vyhovuje víc než RPM.

29. 9. 2026, 08:56 editováno autorem komentáře

Možná je to Fedorou, ale ty předpisy pro OCI kontejnery to hrozně zesložiťují. A možná jsem konzerva a spec mi sedí víc.

Jo, takhle, ty myslíš Fedora flatpaky. To nemá s tím, jak to funguje všude jinde (Flathub, flatpak-builder...) kromě finálního výstupu prakticky nic společného. Tam bylo zadání, že musíme být kompatibilní se zbytkem kontejnerů ve Fedoře a RHELu a modularitou a ten proces sestavování se oproti upstreamu od základu překopal. Použití OCI je ještě dobrá věc, k tomu se časem dopracuje i Flathub, protože OSTree moc neškáluje, ale naroubování na modularitu z toho udělal krkolomný proces. Že se ti nelíbí sestavování flatpaků ve Fedoře, se ti vůbec nedivím. Mně taky ne, ale je to úplně něco jiného než to, jak se to dělá u flatpaků standardně. To mi naopak přijde celkem přátelské a elegantní.

Osobně jsem při balení jedné app měla krapet trable s (pochopitelnou) podmínkou flathubu že build samotný musí probíhat bez přístupu na síť - ale tam za to spíš mohl toolchain flutteru, tuším že se to od té doby zlepšilo.

Ano, s tím jsem se taky jednu dobu natrápil, když jsme do Evolutionu přijali plugin v Rustu. Cargo si chtělo crates stahovat během buildu. Dnes už na to naštěstí existují komunitní skripty, které to předstahují. Nicméně ten požadavek offline buildů je celkem opodstatněný, pro tohle se na Flatpak zlobit nemůžu.

Proc by mel mit uzivatel pravo instalovat naprosto cokoli? To je naopak naprostej mor ve widlich ktery se toho opakovane ruznejma zpusobama a typicky uplne blbe snazej zbavit.

více balíčků potřebují různé verze závislostí. Breaking changes jsou docela časté, už máme takhle forknutých desítky balíčků a buildíme je pod jiným jménem a jiným prefixem.

Flatpak a toolpak pro mě ale není řešení, ale další chaos.

Hlavně na immutable distrech tohle chybí jak sůl. Homebrew je spíš takový hack, binenv pokryje jen binárky, toolbox a distrobox jsou dost neohrabané a na takovýhle usecase dost overkill.

Na tohle se mi líbí systemd-sysext. V Duraniu (image-based varianta postmarketOS, teď vlastně Nury) se přes to instaluje třeba Waydroid a funguje to pěkně. Ale hádám, že u toho je závislost na konkrétní distribuci. Tohle by byla výhoda Toolpaku.

Souhlas, taky jsem celkem zvědav, co se z toho vyvrbí.

Dokážu si vcelku představit ty jednotlivé elementy i to, jak by to mohlo technicky fungovat. Pro nějaké déle běžící procesy asi v pohodě, pro nějaký jednotlivý tool, co se pouští např. ve smyčce z shellu to pak nejspíš narazí na docela citelný overhead. Protože jestli jsem to pochopil správně, tak se to po skončení běhu zas odmountuje ty image z jeho namespace (jinými slovy asi to nebude persistentní jako třeba Snap).

Další věc bude asi i ta organizace a praktické fungování okolo. Jak budou organizované a verzované ty runtimy a sdílené závislosti (třeba u Flatpaku mi tohle přijde docela dobře vymyšlené). Jak bude případně vypadat tooling a jestli vznikne nějaký obecně přijímaný ToolHub (v duchu FlatHub, DockerHub, Sway) pro autory a správce mimo distribuce.

V neposlední řadě je tu samozřejmě také riziko XKCD 927 ;) Obecně vzato to množství nápadů ohledně řešení reprodukovatelných systémů s atomickými rollbacky a řešením praktických problémů kolem je poměrně velké :) A za mě to může snadno sklouznout k šílenému overengineeringu a fragmentaci.

Me se na tohle libily software collections ;)