Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: CPU 12. 05. 2023, 23:28:08
-
Zdravím,
povedlo se někomu dostat vlastní software do oficiálních repozitářů?
Dejme tomu, že bych chtěl na Debianu udělat apt-get install **** bez přidávání cizích zdrojů do sources.
Slyšel jsem, že taková cesta je poměrně trnitá, zdlouhavá a složitá.
Stejně tak jako protlačení aktualizací resp. nové/následné verze balíčků.
Povedlo se to někomu z místních?
Četl jsem nějaké informace k tomu, ale netuším, jaká je realita.
-
i v seznamu si bali vlastni baliky a nikam ven to necpou :-)
cekal bych, ze debian ma standardizovany proces jak overit, ze projekt si zaslouzi oficialni balicek.
jednodussi bude udelat vlastni zdroj a vlastni balicky.
-
Ten proces je standardizovaný a teoreticky i popsaný.
(https://www.debian.org/doc/devel-manuals#maint-guide - skrz jednání s komunitou)
Mě vyloženě zajímala praxe, jestli to někdo podstoupil a jaké má zkušenosti.
-
Pokud jde o Debian, a myslíš si, že daná aplikace by opravdu byla užitečná pro větší počet uživatelů, tak pak asi začít s Experimental repository a kontaktovat jeho správce a zeptat se na konkrétní podmínky a pak zkusit projít schvalovacím procesem.
Ale nevím, zda je šance, aby prošla aplikace, za kterou stojí jen jednotlivec a ne stabilní tým vývojářů. Nikdo nechce v repozitářích neudržovaný odpad.
-
Ano, to je teorie, ale prošel tím někdo? Nějaké reálné zkušenosti?
-
Ano, to je teorie, ale prošel tím někdo? Nějaké reálné zkušenosti?
napr. autor https://www.gpxsee.org tim zkousel projit, zkusenosti ma spatne za nekolik let se to nepovedlo, na abclinuxu (https://www.abclinuxu.cz/zpravicky/gpxsee-11.11) si obcas postezuje, nicmene zaroven tam psal ze z Debianu prisel pozadavek na uvedeni licence v kazdem souboru ktery ignoroval protoze se mu to nelibi ;-)
-
Tu diskuzi jsem prošel a zdá se, no trochu mi přijde, jako by si pacoš z Bohnic psal s pacoši z Kosmonos.
Dej tam licenci. Nééé, dávat jí tam je ztráta času. Nééé, dej tam tu licenci. Nééé, dávat jí tam je ztráta času. Nééé, dej tam tu licenci. Nééé, dávat jí tam je ztráta času.
Alespoň teoreticky to vypadá, že pokud by na jejich požadavek přistoupil, asi by se s ním bavili dál. Hele dík za to info!
-
A nebude jednodussi pridat balik do nejake distribuce ktera je source-based (gentoo napr.) ?
Jednou jsem postoval patch pro implementaci multicastu do PHP/sockets a maintainer me sjel jako ze to ma jet na bsd, solarisu i windows - krome linuxu... coz si mam pry overit sam (jako wtf.. jak? jako malej clovicek) - tak jsem se samozrejme vys*al na nejakou zpetnou podporu OSS. Si vetsina jenom hraje na neco ale nejsou ochotni / schopni spolupracovat s nekym "pod uroven".
Je to bohuzel velice smutny stav veci.
-
A nebude jednodussi pridat balik do nejake distribuce ktera je source-based (gentoo napr.) ?
Bude to prakticky stejně jednoduché jako dostat jej do jakékoliv jiné distribuce nezaložené na Debianu. Dostat balíček do Debianu a do jakékoliv jiné distribuce slovy klasika: "není stejný hřište, není to ani stejná liga, je to úplně jinej sport".
K tomu dostat SW do "normálního" distra stačí "pouze" to, aby ten SW byl nezanedbatelné množině uživatelů užitečný a získal si nějakou základní reputaci. Díky progresivním uživatelům a rozumně nastaveným procesům většiny takových dister se tam ten SW začne pomalu objevovat sám. Jestli je to ale případ tazatelova SW bych se vzhledem k tomu, že se za ten SW zatím stydí i v diskuzi na Rootu, neodvažoval tvrdit...
Naproti tomu dostat SW do Debianu je jako dostat ho do korporátu typu Microsoft, Google nebo Apple. Znamená to dlouholetý (https://www.debian.org/devel/wnpp/requested_byage (https://www.debian.org/devel/wnpp/requested_byage)) boj s korporací a všemi jejími neduhy (nekompetence, lhostejnost, ...). Člověk může mít štěstí, že zrovna v jeho nice narazí v tom korporátu na někoho, kdo umí s věcmi pohnout, ale s větší pravděpodobností bude spíš potkávat lidi, co si jedou "svojí politiku" a svoje zájmy a nějaký "cizí" balíček jim jenom přidělává starosti...
-
... maintainer me sjel jako ze to ma jet na bsd, solarisu i windows - krome linuxu...
To je docela logické, že pokud podporují nějaké spektrum systémů, tak chtějí, aby nová featura fungovala na všech z nich.
coz si mam pry overit sam (jako wtf.. jak? jako malej clovicek)
A tu featuru po tobě chtěli přidat oni, nebo to byla tvoje iniciativa? Pokud tvoje, tak se nediv, že chtěli, aby jsi práci odvedl komplet a ne jen polovičatě, a oni ji po tobě nemuseli dodělávat.
-
Mam v Debianu vice balicku, teda alespon se zda, o nic jsem se ale nesnazil, neco jsem udelal myslim debian friendly a udelal definice pro zabalickovani - a nejak se to do Debianu dostalo.
Nevim, zda to je odpoved na otazku.
-
Dobře ty!
-
Naproti tomu dostat SW do Debianu je jako dostat ho do korporátu typu Microsoft, Google nebo Apple.
Mame appku jak v Apple AppStore tak ve Microsoft Store. Jakmile je v tom totiz komercni zajem (berou si 15%), jsou korporaty velice svolne - a jak vidite z mnozstvi falesnych apek a dokonce viru/trojanu.. tak nekdy az moc svolne. Na druhou stranu, priprava baliku pro distribuce skrze tyto kanaly ma tak striktni pravidla, ze to odeslani za vas v podstate resi primo IDE.
Nekdy to chce trocha presvedcovani a v nasem pripade tomu predchazelo nekolikamesicni schvalovani zameru, ale povedlo se. Samozrejme kazdy update prochazi jakymsi review, a u Applu je celkem videt ze si na tom daji zalezet.. a opravdu ty nove veci overuje nejaka osoba.
... maintainer me sjel jako ze to ma jet na bsd, solarisu i windows - krome linuxu...
To je docela logické, že pokud podporují nějaké spektrum systémů, tak chtějí, aby nová featura fungovala na všech z nich.
coz si mam pry overit sam (jako wtf.. jak? jako malej clovicek)
A tu featuru po tobě chtěli přidat oni, nebo to byla tvoje iniciativa? Pokud tvoje, tak se nediv, že chtěli, aby jsi práci odvedl komplet a ne jen polovičatě, a oni ji po tobě nemuseli dodělávat.
Bylo to neco co jsem potreboval a pouzival sam (na linuxu) a chtel se o to podelit se svetem. Ale ne za cenu, ze musim shanet stroj na kazdou obskurni architekturu a ucit se API jejich custom OS. Proste to je spatny, ze nekdo, kdo tlaci multi-platformovost, neni schopen zajistit testovaci prostredi nebo pomoc s portovanim.
A neco jako #ifdef LINUX samozrejme neproslo - ze takova uzasna featura by byla dostupna jenom na tom spravnem OS :-)
-
Ak je dane distro multiplatformove, tak je logicke, ze chcu, aby vsade bezal rovnako, teda aj apky musia bezat na vsetkych podporovanych platformach.
A preco by oni mali testovat a portovat tvoj kod, ked ty si jeho tvorca. Ich povinnost je akurat otestovat, ze to chodi vsade, kde pozaduju.
Ja tiez v praci neprogramujem v style: u mna to chodi, a ked to chcete dat na server, tak si upravte a otestujte sami.
-
Já jsem zkoušel dostat jen opravu knihovny....
No nedostal jsem nic.
Až vám bude záhadně padat kombinace musl + Chrominum tak si na mě můžete vzpomenout.
-
Ono tie distra nie su take otvorene ako o sebe tvrdia.
Tiez som skusal pretlacit nejake male fixy.
-
tak ono je rozdiel otvorene a otvorene. Predstav si, zeby si do distra mohol ktokolvek pridavat. To by dopadlo, ako arduino - od super kniznic, po totalnu katastrofu, ktora narobi viac problemov, ako uzitku.
otvorenost distra je v tom, ze ty po stiahnuti v nom mozes robit co len chces. Ale pridavat tam, hlavny problem je testovanie. To, ze tebe to funguje neznamena, ze to pojde vsade.
-
Ono tie distra nie su take otvorene ako o sebe tvrdia.
Tiez som skusal pretlacit nejake male fixy.
Mě na tom překvapila hlavně neochota hledat nějaké pragmatické řešení, spíš to vždy sklouzo k nějakému puristickému tlachání o tom, čí je to chyba, nebo proč někde nějaká funkcionalita třeba nemá být (např. když jsem do flashromu dopsal přepínač proto, aby programoval vstupem menším, než je paměť). Neslato se mi to jednou.
-
Ono tie distra nie su take otvorene ako o sebe tvrdia.
Tiez som skusal pretlacit nejake male fixy.
Mě na tom překvapila hlavně neochota hledat nějaké pragmatické řešení, spíš to vždy sklouzo k nějakému puristickému tlachání o tom, čí je to chyba, nebo proč někde nějaká funkcionalita třeba nemá být (např. když jsem do flashromu dopsal přepínač proto, aby programoval vstupem menším, než je paměť). Neslato se mi to jednou.
Pripadne nulova komunikacia.
-
Timhle jsem si prosel a nakonec jsem to vzdal. Resp. zasal jsem se ucit snap a delam jen .msi baliky pro Windows. Kdysi bylo ucelem distribuci usnadnit cestu aplikaci k uzivatelum. Dneska distribuce brani primemu kontaktu vyvojari s uzivateli. Proto to dneska tolik aplikaci distribuje jako snap anebo docker image.
Moje aplikace uz dokonce balik v Debian/Arch mela ale byla totalne neudrzovana.
Problemy na ktere jsem narazil
- Balik je neudrzovany ale spravce baliku ma uplne jiny nazor na pouziti aplikace nez ja(autor) a pridava do ni patche ktere omeziji funkcionalitu
- FSF zmenila adresu a ja musel aktualizovat licenci GPL s tou novou adresou
- "Mas projektu adresar extlibs. Proc?, udelej separatni baliky pro kazdou knihovnu i kdyz jsou to tvoje vlastni knihovny a nikdo jiny nepouziva".
- "Mas v projektu opatchovanou verzi knohovny ANTLR". Patch resi SEGFAULT, ktery mi nehodlame opravit. Prejdi na verzi knihovny z distribuce"
- Nasli jsme v tvym projektu neco co vypada jako tabulka znaku Unicode, prejdi na knihovnu libICU.
Vsechny ty pozadavky by byli tak min. 6 mesicu prace a vybec neni jisty jestli by si pak nejaky purista nevymyslel nejaky dalsi "problem". A na takovyhle veci uz jsem starej.
-
- "Mas projektu adresar extlibs. Proc?, udelej separatni baliky pro kazdou knihovnu i kdyz jsou to tvoje vlastni knihovny a nikdo jiny nepouziva".
- "Mas v projektu opatchovanou verzi knohovny ANTLR". Patch resi SEGFAULT, ktery mi nehodlame opravit. Prejdi na verzi knihovny z distribuce"
- Nasli jsme v tvym projektu neco co vypada jako tabulka znaku Unicode, prejdi na knihovnu libICU.
Tohle má společného jmenovatele. Jak jste vy moc starý na tolik práce, tak oni mají dost práce i bez toho, aby museli řešit několik bundlovaných kopií dat a knihoven v případě třeba CVE. Proto všechny velké distribuce zakazují bundling. Opraví se distribuční knihovna a všechny ostatní programy jsou tím automaticky opraveny taky.
Vaše ušetřená práce by byla přidaná práce pro maintainery na roky dopředu.
Mám balíky ve Fedoře (no měl jsem), dělal jsem i maintainera v RHELu a moc dobře vím co ta údržba distribuce obnáší. Obzvláště u projektů, kterým se odmlčí autor, protože se ožení, změní práci, přejete ho auto (reálná a zažitá situace..).
Chápejte, že to ani pro ty správce není tak snadné, jak to vypadá.
-
Jo taky jsem se poukousel dostat patch to Hibernate. Clovek se kterym jsem na tom spolupracoval ale odesel z RedHatu a tim to skoncilo, jako clovek z ulice nemam sanci. Lide kteri ten ten SW vyviji jsou pysni na sve vize a feedback od uzivatelu z produkce je nezajima.
PS: Ten clovek z RedHatu pridal do Hibernate logovani pomalych SQL dotazu a ja k tomu pridal lepsi formatovani tech SQL dotazu. Lidi z Hiberante me odbyli s tim ze to neni potreba.
-
Nemali by o tom co bude v distribucii rozhodnut skor jej pouzivatelia ako par jednotlivcov?
Ale podla toho co tu citam, tak sa necudujem, ze aj velke a zname firmy si radsej zalozia vlastne repozitare, je to asi menej narocne ako sa dotahovat s tymito ludmi.
-
Nemali by o tom co bude v distribucii rozhodnut skor jej pouzivatelia ako par jednotlivcov?
To se lépe řekne, než udělá. Musíte mít nějaký způsob jak toho uživatele ověřit. Takže ve Fedoře to chce účet, bug na package review a proven packager sponzora.
Na větší změny jsou volby do FESCo (Fedora steering comitee). Také existují procesy na velké změny atd, ale finálně rozhoduje FESCo. Náhodný kolemjdoucí prostě tu sílu mít nemůže, protože nemá tu zodpovědnost (ani zkušenosti).
Pro balíky mimo Fedoru je tu copr, kde si každý může uveřejnit co chce. Ale nemá to ty garance. Ubuntu myslím mělo něco podobného s repozitáři z launchpadu. Debian samotný v tomto směru neznám.
-
Chapu, ze je blby kdyz je tahle "politika" u bugfixu, ale kde presne vidite problem u aplikaci? Pouzivam nekolik aplikaci temer vsude a jsem docela rad, ze nemusim resit pomalost/neochotu spravcu distra (nebo proste jen komplikovanost te spravy) a mam to primo ze zdroje.
Chapu spravce distra, ze nechteji za par let neco vyndavat protoze tvurce proste neni.
-
Lide kteri ten ten SW vyviji jsou pysni na sve vize a feedback od uzivatelu z produkce je nezajima.
Zajímá, ale musí mít nějaký hmatatelný a měřitelný přínos (nejlépe podložený daty). Oni ten kód následně musí udržovat a testovat, tak prostě nemohou přijmout cokoliv od kohokoliv.
Nicméně na sebestředné jedince samozřejmě narazíte v IT občas taky..
-
Tak asi by som odporucil skusit ho dostat na flathub. Tam jednu svoju aplikaciu mam a jedine co skritizovali bol samotny JSON manifest popisujuci ako sa ma skompilovat a potom ze chyba metadata XML subor kedze z neho sa generuje web stranka s popisom aplikacie.
-
Zajímá, ale musí mít nějaký hmatatelný a měřitelný přínos (nejlépe podložený daty). Oni ten kód následně musí udržovat a testovat, tak prostě nemohou přijmout cokoliv od kohokoliv.
To platí pro přispívání přímo do projektů, ale úkol distribucí dle mě není snažit se být chytřejší než autoři projektu. Takové snahy vedou akorát na Debianí OpenSSL fiasko (https://research.swtch.com/openssl)... Samozřejmě, že do distribuce taky nelze přijmout úplně všechno, ale pokud s projektem roky nemají problém (https://repology.org/project/gpxsee/versions) od Fedory přes OpenBSD až po "ultra-Stallmanovský" Guix, není důvod proč by měli mít problém zrovna v Debianu...
Jak už se tady několikrát psalo, je to samozřejmě hodně o konkrétních lidech, na které člověk narazí, ale některé distribuce ty "sebestředné jedince" prostě přitahují víc a některé méně. Ono je to hodně vidět už na těch procesech, které v těch distribucích jsou nastavené. Zatímco v Arch linuxu potřebujete k zařazení do distribuce dostat na jedno místo triviální PKGBUILD (https://github.com/archlinux/svntogit-community/blob/packages/gpxsee/trunk/PKGBUILD), V Debianu to znamená sáhodlouhé diskuze (https://lists.debian.org/debian-gis/2018/12/msg00000.html) v různých "podvýborech" a kontakt s roztříštěnou, archaickou a v každé skupině jinak fungující infrastrukturou...
-
Tak asi by som odporucil skusit ho dostat na flathub.
Opravdu na Linuxu chceme mít část SW v distribučním repu, část na Flathubu, část v NPM, část v CPANu, část v ... ?! Před 20 lety jsme se "major platformám" vysmívali, že se na ně SW stahuje po celém internetu. Dnes to směřuje k tomu, že na Windows/OS X/Androidu je všechen SW v jednom App store a na Linuxu po celém internetu v podobě 275 typů balíčků... Jo, pokrok nezastavíš!
-
Opravdu na Linuxu chceme mít část SW v distribučním repu, část na Flathubu,
ANO! Jako uživatel Fedora Silverblue přesně to chci :) Umožňuje mi to používat aplikaci (nejnovější) jakou potřebuji na systému, který chci (třeba i starší verze..), aniž bych musel řešit závislosti.
Dnes to směřuje k tomu, že na Windows/OS X/Androidu je všechen SW v jednom App store a na Linuxu po celém internetu v podobě 275 typů balíčků... Jo, pokrok nezastavíš!
Jenže Flatpak funguje jinak. Je hierarchický, takže všechny hlavní závislosti se automaticky upgradují jen jednou pro každý Runtime (a těch je jen pár). Appimage i aplikace v App storech mají závislosti bundlované a neumí je updatovat...
Tak asi by som odporucil skusit ho dostat na flathub.
Třeba u toho zmíněného gpxsee to autor explicitně odmítl. Před pěti lety.. trošku jsem do něj šťouchnul, třeba ho to přiměje se zamyslet :)
V Debianu to znamená sáhodlouhé diskuze (https://lists.debian.org/debian-gis/2018/12/msg00000.html) v různých "podvýborech" a kontakt s roztříštěnou, archaickou a v každé skupině jinak fungující infrastrukturou...
No ta hlavní námitka o tom, že autor gpxsee nepřijímá žádné patche je pro Debian dost zásadní:
Only localization contributions are accepted at the moment, code pull requests will be rejected.
Debian si zakládá na některých principech, které ostatní moc neřeší. A tohle je červený hadr na býka.
-
No ta hlavní námitka o tom, že autor gpxsee nepřijímá žádné patche je pro Debian dost zásadní.
Debian si zakládá na některých principech, které ostatní moc neřeší. A tohle je červený hadr na býka.
"Zakládat si na principech" si teda představuju jinak, než že je pro někoho něco "zásadní" jenom tam, kde se mu to hodí... Kdyby skutečně šlo o principy, tak v Debianu není třeba SQLite, asi nejznámější příklad Open-Source, not Open-Contribution (https://sqlite.org/copyright.html) SW co v Debianu je.
A to se ještě vůbec nebavíme o tom, proč by to měl být nějaký zásadní problém zrovna pro Debian, když ostatní distribuce s tím žádné problémy během těch let co tam GPXSee je nezaznamenaly...
-
Jenže Flatpak funguje jinak. Je hierarchický, takže všechny hlavní závislosti se automaticky upgradují jen jednou pro každý Runtime (a těch je jen pár). Appimage i aplikace v App storech mají závislosti bundlované a neumí je updatovat...
Ten problém je ale právě v tom, že funguje jinak. Jinak než těch 274 dalších balíčkovacích mechanismů, které by preferoval zase někdo jiný. Pokus nahradit DEB/RPM, Appimage, NPM, CPAN, ..., pomocí Flatpacku opravdu neskončí jedním univerzálním standardem (https://xkcd.com/927/)...
Třeba u toho zmíněného gpxsee to autor explicitně odmítl. Před pěti lety.. trošku jsem do něj šťouchnul, třeba ho to přiměje se zamyslet
Autor GPXSee se na toto téma zamýšlí pokaždé, když narazí na nějaký další SW distribuovaný pomocí dalšího balíčkovacího systému, který ještě ve svém OS nemá. Ale zatím vždy došel k závěru, že sám pomáhat tomuto šílenství nehodlá...
-
Ten problém je ale právě v tom, že funguje jinak. Jinak než těch 274 dalších balíčkovacích mechanismů, které by preferoval zase někdo jiný. Pokus nahradit DEB/RPM, Appimage, NPM, CPAN, ..., pomocí Flatpacku opravdu neskončí jedním univerzálním standardem (https://xkcd.com/927/)...
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. A to nemluvím o tom, že musí mít práva instalovat balíčky.
AppImage je konkurence Flatpaku, ale neumí updaty, neumí Runtimes atd. NPM, CPAN, pip, cargo a podobně nejsou konkurencí. Systémové knihovny by měly být zabalené, desktopové (nezávislé na systému) si to nějak musí zařídit a pro vývoj se dá instalovat jiná sada knihoven pro každý projekt.
Takže ve skutečnosti by desktopová aplikace dneska vůbec nemusela podporovat třeba RPM, protože Fedora podporuje Flatpak ve všech spinech. A možná ani DEB, protože Ubuntu zase preferuje AppImage...
-
Kdyby skutečně šlo o principy, tak v Debianu není třeba SQLite, asi nejznámější příklad Open-Source, not Open-Contribution (https://sqlite.org/copyright.html) SW co v Debianu je.
Ale SQLite přijímá patche
"the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."
stačí jen "podepsat" formu CLA. Jenže gpxsee toto neumožňuje (na webu má jen vágní komentář, že možná někdy..).
-
Ale SQLite přijímá patche
Já tam teda čtu toto: "In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to make a suggested change, and include a patch as a proof-of-concept, that would be great. However please do not be offended if we rewrite your patch from scratch."
Navíc celé je to taková akademická diskuze, protože mezi ty "principy" otevřeného přispívání z hlediska Debianu těžko bude patřit nutnost souhlasit s nějakým CLA (a že některé ty CLA, třeba u Qt jsou dost "výživný"). To by jeden taky mohl klidně tvrdit, že i přispívat do GPXSee je v pohodě možné, protože některé druhy patchů ten projekt přijímá a v případě zajímavých patchů je tu příslib tuto množinu rozšířit...
-
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. Výsledek pak je, že uživatel potřebuje 4 (se systémovým mechanismem - RPM/DEB/...) různé systémy pro instalaci programů.
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.
-
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.