Vlákno názorů k článku
Elementary OS chce AppCenter pro každý Linux
od danielsoft - "každý Linux" může mít jiný balíčkovací systém: jak...
-
"Balíčky by měly být založeny na Flatpaku."
Problem je, ze ja nechci programy ve flatpaku, ja chci normalni balicek integrovany v balickovacim systemu meho OS, pouzivajici stejnou knihovnu jako ostatni programy, a ta knihovna je updatovana balickovacim systemem. A ne aby kazdy program mel vlastni verzi nezaplatovane knihovny.
-
To je ovšem problém i distribucí. Abyste dostal balíček do distribuce, tak musíte projít review, ale pak už má maintainer dost volnost v tom, co bude, respektive nebude dělat. Některé distribuce rovnou rezignují na udržování celých repozitářů, jiné mají pravidla, která říkají, že balíček musí být řádně udržovaný, aby v distribučních repozitářích zůstal, ale reálně se to slabě nebo vůbec nevymáhá.
A bundluje se taky jako o život. Některý software už člověk ani s dynamickým linkováním na systémové knihovny pořádně nerozchodí nebo to obnáší takové množství práce, že se to nevyplatí. Sám k jednomu balíčku bundluju knihovnu, protože to tak upstream prostě má a stejně ji nic jiného ve Fedoře nepoužívá, tak by moc nemělo smysl ji odbundlovávat. Fedora patří mezi ty distribuce s přísnějšími pravidly a stejně mi dnes stačí jen do spec filu uvést, že upstream trvá na bundlování, a napsat tam, co bundluju (pro případný security scan).
Tím nechci obhajovat Flatpak vůči distribučním balíčkům. Jen poukázat na to, že distribuce dnes opravdu nejsou ten ideální svět perfektního sdílení knihoven a poctivé aktualizace balíčků, za který jej pořád někteří mají. Nakonec stará se o to omezený počet lidí a drtivá většina z nich ještě ve volném čase. Nelze čekat zázraky.
-
Nikdy jsem si srovnání většího počtu aplikací nedělal, takže průměrnou hodnotu vám neřeknu. Dost se to liší. Od aplikací, které nad rámec runtimu nic nepotřebují a jejich flatpaky jsou tak zhruba stejně velké jako jejich balíčky v distribucích, až po aplikace, které si zase bundlují téměř vše a u kterých jsou to potom násobky velikosti.
-
Jakým způsobem se kontroluje zdrojový kód u balíčků Fedory? Na Manjaru se mi jednou stalo, že jsem se chtěl před aktualizací balíčku podívat na konkrétní změny ve zdrojáku. Manjaro má zdrojáky na GitLabu, tam ale daná verze balíčku nebyla, tak jsem se ptal ve fóru a bylo mně sděleno, že maintainer to má asi jen u sebe na localu a na GitLab to zapomněl nahrát (později jsem zjistil, že se to stává často). Což mě zarazilo a zeptal jsem se jak teda zjistím, že tam maintainer nevložil trojského koně, na čež mi bylo sděleno, že i kdyby ty zdrojáky na GitLabu byly, tak stejně MUSÍM důvěřovat maintainerovi co nakonec dal do repozitáře.
Na stránkách https://copr.fedorainfracloud.org jsem si kdysi všiml, že tam jsou nějaké reporty z vytváření balíčků. Dá se na to u Fedory spolehnout a dá se takový systém balíčkování označit za důvěryhodný, tzn. že to co je ve zdrojáku odpovídá tomu co je nakonec v binárním balíčku? Nebo i tam jsem odkázán na důvěru v maintainery? Případně znáte nějaký přehled jak "důvěryhodné" je vytváření balíčků u různých distribucí (nějaké srovnání)?
-
Copr je služba pro externí repozitáře a jediné požadavky jsou tam licenční a patentové, jinak si tam můžou lidi buildit co potřebují.
Repozitáře balíčků ve Fedoře najdete tady: https://src.fedoraproject.org/projects/rpms/*
Fedora neumožňuje nahrát binární balíčky, vše musí být sestavené v infrastruktuře Fedory. Když správce balíček aktualizuje, udělá změny ve spec filu, který nahraje do repozitáře balíčku, odkáže se v něm na zdrojáky v upstreamu, které se mají použít, a ještě ty zdrojáky nahraje do infrastruktury Fedory. Buildovací systém Koji to potom vezme a balíček sestaví pro jednotlivé architektury. Historie veškerých buildů včetně zdrojových balíčků tam je k dispozici, takže si člověk může prověřit nejen jednu změnu, ale všechny: https://koji.fedoraproject.org/koji/
Nemálo distribucí umožňuje správcům nahrávat binární balíčky, které byly sestavené jinde, ale IMHO je to špatně z důvodů, které uvádíte. Debian se alespoň snaží o reprodukovatelné buildy, takže člověk si může balíček znovu sestavit a porovnat s tím, co vytvořil správce balíčku, ale pořád mi to nepřijde tak transparentní, jak to má Fedora.
12. 2. 2020, 11:43 editováno autorem komentáře
-
Diky za odpověď. Jestli se nemýlím, tak i OpenSuse má obdobu Koji a to OBS. Našel jsem i nějakou srovnávací tabulku. ve které je Ubuntu se svým Launchpadem, ale Debian tam opravdu není.
-
Na druhou stranu, několik měsíců používám experimentálně jednu aplikaci ve Flatpaku a občas se kolem ní dějí zvláštnosti; čas od času mi prostě zmizí z menu. Zatím všechny tyto případy korelují s vysokou zátěží HDD a když ta přejde, tak se (třeba po minutě - dvou) ikona znovu objeví a jde spustit. Moje teorie je, že se aplikace automaticky aktualizuje. Z pohledu BFU je pak ale spustitelnost této apky něčím hodně nestabilním (při nějakých konstelacích nelze spustit, aniž bych něco udělal), nicméně jsem si ještě nenašel čas se zase jednou ponořit do hlubin systému a pátrat, v čem je problém a zda je to vlastnost flatpaku, či jen konkrétní aplikace.
-
FíkZlatý podporovatelkupodivu i ruční aktualizace Flatpaku trvá dlouho, i když mám jen jednu aplikaci
time sudo flatpak update -y
trvalo 9 minut, předtím aktualizováno asi před 3 týdny
-
J L (neregistrovaný)
Těch appcenter je mnoho, ale všechny naráží na to, že sice projekt dotáhnou k spuštění, ale to je asi tak všechno.
Flatpak byl sice dobrým nápadem, ale jeho rychlost stahování je nízká, chybovost či když už začne stahovat plnou rychlostí tak potřebuješ trickle, aby sis mohl vůbec projít něco na netu. Hlavně nikdo se o flat nestará... Třeba příkladem je Wine projekt, kdy sice vyjde klasickou cestou update, ale pro flat je to třeba o den či dva... A je tu mnoho jiných, který jen vydají a tím to tak končí.
A upřímně ta představa jednoho Appcentera je fakt hezká, snad se i podaří.
-
Tak hlavně tím jedním zdrojem aplikací pro všechny linuxové distribuce chce být hodně subjektů. Flathub, Snap Store, AppImageHub... AppCenter opravdu nepřináší nic revolučního. A vzhledem k tomu, že mají dost striktní přístup (buď podle nás nebo bez nás), si myslím, že budou pro ostatní méně stravitelní.
Nicméně to, že chtějí svůj obchod otevřít ostatním, je rozhodně pozitivní krok. Doteď to bylo totiž přesně naopak. Když někdo zabalil nějakou jejich aplikaci ve Flathubu nebo distribuci, odmítali řešit problémy uživatelů těchto verzí a požadovali, aby na ně dané verze neodkazovaly.
