Portál AbcLinuxu, 30. dubna 2025 13:12
flatpak run --nofilesystem=home MyApp
) nebo trvale (flatpak override --nofilesystem=home MyApp
). Práva v manifestu jsou jen default, který si může uživatel upravit dle potřeby.
Kernel ABI != userspace ABIVe smyslu, ze "stable" distra neslibuji stabilni kernel ABI ale jen userspace ABI? Tohle je priklad, na ktery jsem narazil zrovna vcera, kdy slib stabilniho ABI nic neznamena. Pripady, kdy se neco podobneho povedlo klukum z flatpaku si budes muset najit sam (maji bugzillu pro runtimes?).
--device=dri
(doufám, že nekecám).
Pokud se ma aplikace spoustet po startu/ovladat pres init skripty, jak je toto vyreseno?Není vyřešeno. Pro takové aplikace není Flatpak určen.
/var/lib/flatpak
. To je daleko lepší situace než typické dilema AURisty, kdy WeirdAppA chce knihovnu libLegacyB která teď začala kolidovat s libNewVersionB, na které jako na potvoru závisí dalších patnáct balíčků a dokud to někdo nějak nevyřeší, nemohu instalovat aktualizace.
Pochopil jsem, že se ti koncept flatpaku nelíbí, okay, jak bys to tedy řešil ty?Dodrzovat ABI kompatibilitu. Pokud by mi abclinuxu nevracelo "413 Request Entity Too Large", tak bych vlozil jako prilohu build vimu, ktery pouziva dynamicke linkovani a bude fungovat na vsech normalnich distribucich od rhel5 po Ubuntu 17.10 - to znamena na vetsim mnozstvim distribuci nez flatpak. Navic diky tomu ze ma dynamicky linkovane libtinfo se i lepe integruje do systemu. Je mi jasne, ze to takto nefunguje pro gtk aplikace, protoze gnome "vyvojari" (narozdil od core knihoven) na to totalne kaslou. Sam mam takovou prihodu, kdy jsem resil velice neprijemny bug s gsettings v ubuntu. Resetovalo se nastaveni klavesovych zkratek po restartu. Tento bug tam vydrzel pres dva roky a minimalne jeden ubuntu maintainer o nem vedel, nastavil si workaround a neresil; po dvou letech me to nastvalo tak, ze jsem stravil tri dny v gdb a fixnul to za ne, ale ocenuji, ze pak aspon patch bez kecu prijali (na zaklade predchozich zkusenosti jsem patch ani nezkousel dostat do upstreamu gnome - to by proste vyhnilo v bugzille). Je mi jasne, ze naucit vyvojare s takovymto pristupem nerozbijet ABI je mimo realitu. Na druhou stranu, jine opravdove reseni neexistuje. Flatpak apod. jsou takove workaroundy, kde se povazuje za uspech, ze se aplikace povede spustit.
Ne, minimálně pro Flathub to je vyřešené tak, že do něj lze přidávat témata jako rozšíření runtimu.Jo to je presne ten "hack", ktery myslim, tzn. integrace nulova. Takze se nic nezmenilo, diky za info.
Neco jako treba:
# for LINE in $(rpm -qR httpd);do rpm -q --whatprovides $LINE; done | sort | uniq | grep -v "no package provides" apr-1.2.7-11.el5_6.5 apr-util-1.2.7-11.el5_5.2 bash-3.2-32.el5 chkconfig-1.3.30.2-2.el5 coreutils-5.97-34.0.1.el5_8.1 db4-4.3.29-10.el5_5.2 expat-1.95.8-11.el5_8 file-4.17-28 findutils-4.2.27-6.el5 gawk-3.1.5-16.el5 glibc-2.5-107 httpd-2.2.3-76.0.1.el5_9 initscripts-8.45.42-1.0.3.el5_8.1 libselinux-1.33.4-5.7.el5 mailcap-2.1.23-1.fc6 mktemp-1.5-24.el5 openldap-2.3.43-25.el5_8.1 openssl-0.9.8e-26.el5_9.1 pcre-6.6-6.el5_6.1 shadow-utils-4.0.17-21.el5 zlib-1.2.3-7.el5
Jsem si nevsiml ze by si to tahlo vsechny zavislosti sebou. A httpd je takova obvykla unixova aplikace pokud se nepletu. Instalace pres rpm/deb mi proste prijde k systemu cistejsi a obecne vzato i bezpecnejsi.
Co se klonování z gitu týče, jde uvést branch, tag i konkrétní commit, který se má použít.Aspoň, že tak.
Flatpak se IMHO nesnaží být "lepší balíčkovacím systémem" jako spíš rozumně kompromisní alternativou k nativním balíčkům. Jsem zvědavý, zda a kam se možnosti Flatpaku posunou.Obávám se, že nativní balíky budou postupně mizet. Tady je totiž problém v tom, že vytvořit správně balík třeba pro Debian není vůbec jednoduché a dostat ho do oficiálních repozitářů jakbysmet. Vývojáři ani uživatelé nechtějí čekat. Dnes se proto lze často setkat s „oficiálními“ upstream repozitáři (ať už provozovaných na vlastním serveru, nebo třeba jako PPA). To na první pohled vypadá jako dobré řešení, dokud není třeba řešit závislosti napříč těmito repozitáři. Balík foo z jednoho repozitáře může záviset na balíku bar z jiného repozitáře, který uživatel nemá přidaný. Konflikt pak musí vyřešit ručně on sám (v tomto případě nalezením a přidáním repozitáře, který obsahuje patřičný balík). V dlouhodobém horizontu se také můžou objevovat problémy se zanikajícími repozitáři. Nabízí se myšlenka, jestli by závislost neměla být specifikována jen jménem balíku, ale ještě zdrojem. To ovšem neřeší ty případné zanikající repozitáře. Nakonec by tedy asi bylo nejlepší něco jako IPFS, kdy balík bude specifikován jménem, verzí (viz dále) a nějakým podpisem – klasický checksum nelze použít, protože každá verze bude mít jiný. Co se týká verzí, bylo by ideální pevně odlišit verzi API od verze softwaru, nebo striktně dodržovat konvence. V praxi nevím, jaký konsenzus v případě schéma <major>.<minor>.<patch> panuje ohledně situací, kdy v rámci (security) bugfixu je nutné rozbít zpětnou kompatibilitu. Inkrementuje se jen patch a mávne se nad tím rukou s tím, že „správně napsané programy by to rozbít nemělo“? Takže by existoval jen jediný decentralizovaný repozitář (provozovaný např. na IPFS). Závislost by byla určená jménem balíku, podpisem, co nejméně restriktivní verzí (např. 1.2.*, pokud je garantováno, že API je stejné; alternativně lze také zavést další kvalifikátory, např. že patch musí být větší nebo roven nějaké hodnotě apod.) a dále referenční verzí, se kterou byl daný program původně testován. Pokud by v systémech existovalo cachování balíků (nebo způsob jak je rekonstruovat z instalovaných souborů a minimálních dat držených v cachi package manageru), šlo by za předpokladu, že by systémy byly do IPFS běžně zapojeny zajistit, že dokud lidé budou libovolný balík dané verze používat, bude k dispozici i ostatním. Referenční verze má spíše dokumentační význam: Pokud po upgradu nějaké knihovny přestane program fungovat, uživatel tuší, na jakou verzi by měl zkusit downgradovat (i třeba za cenu, že bude riskovat bezpečnostní zranitelnost – to už je jeho volba). Balíčkovací systém by s tímto případně mohl i automatizovaně pomoci. Prerekvizitou samozřejmě je, že balíčkovací systém bude umět držet více verzí stejně pojmenovaného balíku. Ostatně, v systému, který naznačuji, by název měl rovněž spíše dokumentační význam než cokoliv jiného. Závazný je spíše nějaký ten podpis. IPFS zmiňuji jen jako příklad, možná se na toto použití ani nehodí. Podstatná je ta myšlenka jednoho decentralizovaného depozitáře, ne konkrétní technické provedení.
215 text files. 215 unique files. 6 files ignored. github.com/AlDanial/cloc v 1.70 T=0.70 s (301.2 files/s, 26595.5 lines/s) ----------------------------------------------------------------------------------- Language files blank comment code ----------------------------------------------------------------------------------- C++ 88 2307 134 8636 C/C++ Header 100 1103 70 3633 Qt 20 0 0 2313 Prolog 1 22 0 270 Markdown 1 18 0 55 Windows Resource File 1 19 23 28 ----------------------------------------------------------------------------------- SUM: 211 3469 227 14935 -----------------------------------------------------------------------------------Takže kvůli cca 9k řádkům v C++ (dodám že to je počet který by Gentoo emerglo jedním příkazem snad dřív než by se ten Flatpak nainstaloval) bude sebou aplikace tahat co? Qwt, QT5, LEMNG, … GNUGMP? Pokrok prostě nezastavíš. Ještě by mě zajímalo kolik má kB vlastní binárka toho PeakMasteru a kolik vlastní balíček ve Flatpaku. Jako pro nějaké velké aplikace typu LibreOffice, GIMP (i když i ten mám přeložený svůj v několika verzích a přitom naprosto bez problémů) budiž, ale tohle kvůli nějakému grafickému bindingu na pár knihoven který by se hodil spíš do nějakého AppStoru?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.