Jenže žádný z těch 274 balíčkovacích systémů (a tolik jich zase není) neřeší nezávislost desktopových aplikací na jádru systému. Takže každý uživatel pak musí řešit, že si aplikaci nemůže pustit v té verzi, kterou potřebuje.
Tohle dnes řeší minimálně 3 balíčkovací systémy - Appimage, Flatpack a Snap. Každý z nich má samozřejmě nějaká plus a nějaká mínus. Vy preferujete Flatpack, ale někdo jiný Snap a další zase Appimage.
Máte pravdu, na Snap jsem zapomněl. Canonical ten jeho "App store" drží bohužel dost "uzavřený".
Appimage se neinstaluje a typicky nemá žádnou integraci se systémem balíčků, je to takový ekvivalent DMG z OS X.
O Flatpaku už jsem mluvil. Je zaštítěný Free Desktopem, nativní v Gnome, umožňuje repozitáře třetích stran... takže chápete proč ho mám raději než Snap. (Ale uživatelé Ubuntu by možná mluvili jinak)
Výsledek pak je, že uživatel potřebuje 4 (se systémovým mechanismem - RPM/DEB/...) různé systémy pro instalaci programů.
RPM/DEB se postupně ukázaly jako nevhodné pro rychle se vyvíjející desktopové aplikace. Obzvláště je to patrné na tom Debianu, který je hodně konzervativní. Provozovat stable základ a zároveň aktuální unstable/testing aplikace není až tak úplně triviální.
Fedora měla zase jiný problém, upgrade každého půl roku, často komplet překopané knihovny..
A obojí jak RPM tak DEB vyžaduje práva administrátora pro instalaci aplikací. Do příchodu AppImage byly jedinou uživatelskou možností statické binárky nebo configure/make do lokálního prefixu.
Navíc v dnešní době malware je poněkud riskantní instalovat věci ze zdrojáků. I ty AppImage jsou dost na hraně.
Flatpak nebo Snap tyto problémy řeší, poskytují sandbox s omezením práv aplikace.
NPM, CPAN, pip, cargo a podobně nejsou konkurencí.
Těžko říct, jestli to nazývat konkurencí, ale rozhodně to jsou další balíčkovací systémy, které musí uživatel mít, pokud si chce instalovat nějaký program. Třeba spustit si běžný moderní(čti: hipsterský) JS program z Githubu je bez NPM prakticky nerealizovatelné. A dtto pro Python a PIP.
To je asi tak stejná úroveň, jako nutnost použít cargo pro nainstalování závislostí Rust zdrojáků. Tohle je typicky vývojářské použití a většina obyčejných uživatelů npm používat nebude (osobně mi pár _Gigabyte_ javascriptových zdrojáků u malého webového projektu přišlo dost šílené).
Pip / Virtualenv pro Python jsou na tom podobně. Obzvláště ve chvíli, kdy uděláte upgrade systémového Pythonu a venv prefixy přestanou fungovat, protože symlinky jsou na konkrétní verzi, která zmizela.
36 Odpovědí
11693 Zhlédnutí