Jeden den s Flatpakem

21.3.2018 02:03 | Přečteno: 3758× | | poslední úprava: 21.3.2018 11:20

Až příliš praktická ukázka, jak pomocí Flatpaku připravit k distribuci netriviální aplikaci...

Distribuce vlastních aplikací pro Linux dostatečně bezúdržbovým způsobem, který by nevyžadoval aspoň občasnou kontrolu, zda se nezměnilo ABI nějaké knihovny je obecně trochu problematická. Tím hůře, pokud chce člověk cílit na více než pár vybraných distribucí. Dosud jsem to řešil masivně statickými buildy, které si maximum závislostí nesly se sebou v jedné olbřímí binárce. Přístup je to sice možný ale dost pracný už jen proto, že takto uhnětenou binárku je potřeba alespoň na pár cílových distribucích stejně otestovat. Dále je třeba počítat s některými omezeními statických sestavení; typicky třeba GUI aplikace linkované proti statickým Qt působí ve zbytku systému jako pěst na oko, protože nemohou použít systémové stylovací pluginy. Před pár dny jsem jen tak zkusil spustit binárku, co jsem zkompiloval zhruba před dvěma lety. Samozřejmě se to nepodařilo, i když jsem se setsakra snažil udržet množství závislostí na systémových knihovnách na minimu. Můj pokus zkrachoval na knihovně libgfortran.so.4, zatímco moje binárka počítala s verzí 3. Protože na ruční udržování balíčků pro různé distribuce nebo pravidelnou kontrolu, která ze závislostí se zase rozbila nemám kapacity, rozhodl jsem se pro další projekt použít odlišný způsob distribuce.

Hello, Flatpak

Flatpak je platforma pro distribuci binárních balíčků vyvíjená Red Hatem a alternativa ke Canonicalímu Snapu. Koncept Flatpaku je založen na tom, že se aplikace sestaví proti konkrétní verzi nějakého runtimu, který si uživatel stáhne spolu s balíčkem aplikace. Runtimy jsou samozřejmě verzované a (zatím) jich není tolik, aby vzniklo DLL Hell, jaké umí vymyslet akorát v Redmondu. Pokud aplikace závisí na něčem, co ve standardních runtimech není, zkompiluje se taková závislost proti stejnému runtimu jako aplikace a distribuuje se najednou spolu s aplikací. Flatpakové balíčky se instalují odděleně do /var/lib/flatpak (případně ~/.local/share/flatpak) a běží sandboxované; nemohou tedy nabořit zbytek systému. Díky tomu se autor aplikace navíc nemusí bát, že by jeho balíček s něčím kolidoval. Ač není základní dokumentace Flatpaku vůbec špatná, omezuje se pouze na triviální ukázku, která je pro sestavení jakékoliv reálné aplikace obtížně použitelná. Dodatečné informace je nutné vylovit „nasyrovo“ z dokumentace a - v nemálo případech - z flatpakových předpisů jiných projektů, ticketů na GitHubu a podobně. Protože ne všechny funkce Flatpaku se chovají úplně intuitivně, napadlo mne shrnout pár svých poznatků ze zhruba jednodenního klopýtání Flatpakovým polem do nějakého zápisku, určitě to budu ještě potřebovat...

Koho jdeme balit?

Jako případová studie nám poslouží PeakMaster, nástroj pro provádění jistých fyzikálně-chemických simulací. Protože vývoj současné verze i výpočetního podvozku probíhal téměř výhradně na Linuxu (GUI z části na macOS), bylo by docela hloupé, kdyby předkompilovaná binárka existovala jen pro Windows. PeakMaster má v nynější podobně pár exotických závislostí, na kterých je možné ukázat různé možnosti, jak zaflatpakovat netriviální program.

Závislostní strom PeakMasteru vypadá v současné podobě nějak takto:

• Qwt, na Qt postavená sada widgetů pro kreslení 2D grafů
• Qt 5
• LEMNG, knihovna implementující lineární model elektromigrace
  • Eigen, knihovna pro práci s maticemi apod.
  • ECHMETCoreLibs, knihovna poskytující nějaké základní datové typy a výpočetní algoritmy
    • Eigen, knihovna pro práci s maticemi apod.
    • MPFR C++, jednoduchý C++ový wrapper nad knihovnou MPFR
    • MPFR, matematická knihovna podporující floating-point operace s libovolnou přesností
      • GNU GMP, knihovna poskytující číslené datové typy o libovolné přesnosti

Eigen a MPFR C++ existují jen jako hlavičkové soubory a žádnou binární podobu nemají, balíčky s LEMNG a ECHMETCoreLibs byste určitě hledali marně a s GNU GMP a MPFR mohou nastat různé nečekané potíže, viz dále. Navíc MPFR nedávno vyšla ve verzi 4.0.0 s jiným ABI; některé distribuce už ji mají, jiné ne. Motivace pro použití Flatpaku je myslím zřejmá.

Disclaimerová vsuvka

Zápisek, který si původně dával za cíl ukázat, na jaké praktické problémy je možné při přípravě Flatpakových balíčku narazit předvést pár možných řešení se nakonec zvrhl v de-facto návod, jak kompletně sestavit jistý software cílící na velmi specifickou skupinu uživatelů. Protože jsem bytostný nepřítel abstraktních („mějme aplikaci A závisející na knihovnách L1 až L6“) či umělých („ukážeme si to na aplikaci dummy závisející na knihovnách libfoo a libbar“) tutoriálů, použil jsem příklad z opravdové praxe, kdy jsem musel řešit opravdové problémy. Doufám, že postřehy, nápady a doporučení zde zmíněné jsou použitelné daleko šířeji než produkt, který na konci tohoto zápisku vznikne...

Jdeme na to

Všechno experimentování jsem prováděl na virtuálním stroji s Fedorou 27 nainstalovanou z netinstallu. Kromě Xfce, Vimu a Flatpaku jsem nemusel instalovat nic dalšího.

1. Instalace Flatpaku

Na úplném začátku potřebujeme nainstalovat Flatpak a Flatpak builder. Na Fedoře postačí:

$ dnf install flatpak flatpak-builder

2. Příprava prostředí

Flatpak během své činnosti vytváří značné množství pracovních souborů, které je určitě vhodné držet na jasně definovaném místě, už jen proto, že umí zabrat docela dost místa. Naším „kořenovým“ adresářem bude /home/flatpak/flatpak_PMNG

Jako první je nutné přidat repozitář, odkud si Flatpak stáhne potřebné runtimy a SDK. To provedeme takto:

$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Dále potřebujeme nainstalovat příslušné SDK, oproti kterému budeme sestavovat naší aplikaci. Seznam SDKček, která jsou momentálně k dispozici v repozitáři flathub je třeba zde. Protože GUI PeakMasteru je napsané v Qt 5, nainstalujeme runtime a SDK pro KDE.

$ flatpak install flathub org.kde.Platform//5.9 org.kde.Sdk//5.9

Všimněte si, že za jménem balíčku je uvedené ještě číslo verze, resp. název větve. Kdybychom jej vynechali, vynadal by nám Flatpak s následující chybou:

error: Multiple branches available for org.kde.Platform, you must specify one of: org.kde.Platform//5.10, org.kde.Platform//5.9

Konzervativně jsem se držel větve 5.9, protože Qt 5.9 má na rozdíl od 5.10 slíbenou dlouhodobou podporu.

3. Zkušební jízda

Teď máme vše, co potřebujeme pro sestavení zkušebního balíčku. Předpis - či chcete-li manifest, podle kterého Flatpak balíčky sestavuje má formu JSON souboru. Triviální manifest může vypadat třeba takto. My při zkušební jízdě sestavíme ECHMETCoreLibs, protože bez nich se nehneme dál.

Vytvoříme jednoduchý manifest, který stáhne zdrojáky Eigenu a ECHMETCoreLibs a pokusí se je sestavit. Budeme počítat s tím, že manifest dále rozšíříme až do tvaru, který dovede sestavit a zabalit celý PeakMaster. Soubor s manifestem pojmenujeme cz.cuni.natur.echmet.PeakMasterNG.json a umístíme do adresáře ~/flatpak_PMNG.

Hlavička manifestu bude vypadat takto:

"app-id": "cz.cuni.natur.echmet.PeakMasterNG",
"runtime": "org.kde.Platform",
"runtime-version": "5.9",
"sdk": "org.kde.Sdk",

• app-id - Unikátní identifikátor balíčku
• runtime - ID runtimu, vůči kterému balíček sestavujeme
• runtime-version - Verze runtimu
• sdk - ID SDKčka

Hlavička dále obsahuje pole modules, ve kterém jsou uvedeny jednotlivé moduly (jak by určitě nikdo neuhodl) tvořící výsledný balíček. GNU GMP a MPFR jsou již obsaženy v org.kde.Platform, potřebujeme tedy zatím jen Eigen a ECHMETCoreLibs.

Prvek pole modules zajišťující stažení a „sestavení“ Eigenu lze zapsat třeba následovně:

{
	"name": "eigen",
	"buildsystem": "simple",
	"build-commands": [
		"mkdir -p /app/Eigen",
		"cp -r Eigen /app/Eigen",
		"cp -r unsupported /app/Eigen"
	],
	"sources": [
		{
			"type": "archive",
			"url": "http://bitbucket.org/eigen/eigen/get/3.3.4.tar.bz2",
			"sha256": "dd254beb0bafc695d0f62ae1a222ff85b52dbaa3a16f76e781dce22d0d20a4a6"
		}
	],
	"cleanup": [
		"/Eigen"
	]
}

• name - Název modulu, v principu může být libovolný.
• buildsystem - Typ nástroje, který balíček sestaví. V případě Eigenu potřebujeme pouze nakopírovat hlavičkové soubory na vhodné místo, použijeme tedy systém simple.
• build-commands - Seznam příkazů provádějících sestavení a instalaci modulu
• sources - Zdrojové kódy nutné pro sestavení modulu. Eigen je distribuován jako tar archiv, pole sources bude tedy obsahovat jediný prvek. Jednotlivé položky mají následující význam:
  • type - Způsob distribuce zdrojáku, zde archive.
  • url - Odkaz na umístění, kde je archiv k dispozici.
  • sha256 - SHA256 kontrolní součet. Je-li zdrojem vzdálené umístění, je nutné kontrolní součet uvést, jinak se balíček nesestaví.
• cleanup - Seznam souborů či adresářů, které je možné po sestavení balíčku odstranit.

Jistě jste si všimli, že Eigen se kopíruje do adresáře /app. Tento adresář je ve Flatpakovém sandboxu vždy přimountovaný a funguje jako de-facto kořenový adresář. Flatpakový sandbox standardně nedovoluje přístup ke skutečnému souborovému systému stroje - s tímto je nutné počítat a sestavovací skripty a aplikaci tomu přizpůsobit. Pozor na to, že Flatpak není s používáním prefixu /app úplně konzistentní, někdy (většinou) je nutné jej uvést, jindy nikoliv.

Fajn, to bychom měli Eigen, můžeme směle pokročit k sestavení ECHMETCoreLibs. Definice modulu pro ECHMETCoreLibs se liší od té pro Eigen použitím jiného buildsystemu a způsobu, kterým se získá zdrojový kód. ECHMETCoreLibs jsou sestavovány CMakem. Jako buildsystem tedy uvedeme cmake a namísto build-commands použijeme config-opts. Typ zdroje bude nyní git, url bude obsahovat odkaz na příslušný repozitář. Navíc ještě přibude hodnota branch identifikující gitovou větev, kterou chceme naklonovat. Celá definice vypadá takto:

{
	"name": "CoreLibs",
	"buildsystem": "cmake",
	"config-opts": [
		"-DCMAKE_BUILD_TYPE=Release",
		"-DEIGEN_INCLUDE_DIR=/app/Eigen",
		"-DCMAKE_INSTALL_PREFIX=/app",
		"-DCMAKE_CXX_FLAGS=-g"
	],
	"sources": [
		{
			"type": "git",
			"url": "https://github.com/echmet/ECHMETCoreLibs.git",
			"branch": "master"
		}
	],
	"cleanup": [
		"/include"
	]
}

Zkompletovaný manifest jest následující:

{
	"app-id": "cz.cuni.natur.echmet.PeakMasterNG",
	"runtime": "org.kde.Platform",
	"runtime-version": "5.9",
	"sdk": "org.kde.Sdk",

	"modules": [
		{
			"name": "eigen",
			"buildsystem": "simple",
			"build-commands": [
				"mkdir -p /app/Eigen",
				"cp -r Eigen /app/Eigen",
				"cp -r unsupported /app/Eigen"
			],
			"sources": [
				{
					"type": "archive",
					"url": "http://bitbucket.org/eigen/eigen/get/3.3.4.tar.bz2",
					"sha256": "dd254beb0bafc695d0f62ae1a222ff85b52dbaa3a16f76e781dce22d0d20a4a6"
				}
			],
			"cleanup": [
				"/Eigen"
			]
		},
		{
			"name": "CoreLibs",
			"buildsystem": "cmake",
			"config-opts": [
				"-DCMAKE_BUILD_TYPE=Release",
				"-DEIGEN_INCLUDE_DIR=/app/Eigen",
				"-DCMAKE_INSTALL_PREFIX=/app",
				"-DCMAKE_CXX_FLAGS=-g"
			],
			"sources": [
				{
					"type": "git",
					"url": "https://github.com/echmet/ECHMETCoreLibs.git",
					"branch": "master"
				}
			],
			"cleanup": [
				"/include"
			]
		}
	]
}

Zkušební manifest máme připravený, můžeme vyrazit. Build samotný spustíme příkazem:

$ flatpak-builder --repo=PMNG PMNG_pkg cz.cuni.natur.echmet.PeakMasterNG.json --force-clean

• --repo=PMNG - Název lokálního repozitáře udržujícího informace a sestaveném balíčku. Teoreticky není nutný ale balíček by pak nešel exportovat.
• PMNG_pkg - Adresář se soubory tvořící Flatpakový balíček.
• cz.cuni.natur.echmet.PeakMasterNG.json - Náš manifest.
• --force-clean - Není-li adresář PMNG_pkg prázdný, smaž jeho obsah.

Dopadlo-li všechno dobře, měli bychom v adresář flatpak_PMNG najít dva nové podadresáře PMNG a PMNG_pkg. Nahlédneme-li do PMNG_pkg/files, měli bychom tam nalézt vše, co vzniklo sestavovacím procesem uvedeným v manifestu. V našem případě půjde o adresář /lib se čtyřmi knihovnami a příslušnými symlinky. V podadresáři debug jsou tytéž knihovny ještě jednou, tentokrát všech včetně ladicích symbolů. flatpak_PMNG by měl ještě obsahovat skrytý adresář .flatpak_builder kde si builder uchovává cache a stažené zdrojáky.

4. Jízda pokračuje

Úspěšně jsme sestavili úplný základ, můžeme tedy v klidu pokračovat a přidat další z potřebných závislostí. Knihovna LEMNG se sestavuje skoro stejně jako ECHMETCoreLibs, definice modulu je následující:

{
	"name": "LEMNG",
	"buildsystem": "cmake",
	"config-opts": [
		"-DCMAKE_BUILD_TYPE=Release",
		"-DEIGEN_INCLUDE_DIR=/app/Eigen",
		"-DECHMET_CORE_LIBS_DIR=/app",
		"-DCMAKE_INSTALL_PREFIX=/app",
		"-DCMAKE_CXX_FLAGS=-g"
	],
	"sources": [
		{
			"type": "git",
			"url": "https://github.com/echmet/LEMNG.git",
			"branch": "master"
		}
	],
	"cleanup": [
		"/include"
	]
}

Zde je asi vhodné zmínit, že Flatpak sestavuje moduly v tom pořadí, jak jsou uvedeny v poli modules. Dále se předpokládá, že modul uvedený v seznamu níže závisí na modulech před ním. Jakákoliv změna v definici modulu způsobí rebuild všech modulů uvedených pod ním.

5. Přituhuje

Až doposud šlo všechno celkem přímočaře. První výmol na cestě můžeme trefit v případě, kdy musíme sestavit nějaký software, jehož sestavovací proces není možné rozumně nakonfigurovat parametry předanými z příkazové řádky. To je případ třeba knihovny Qwt. Ta předpokládá, že ručně upravíme soubor qwtconfig.pri. Způsobů, jak si poradit, je více. V rámci demonstrace několika možností začneme s variantou kanadského dřevorubce.

1. Stáhneme zdroják Qwt 6.3.1: https://sourceforge.net/projects/qwt/files/qwt/6.1.3/qwt-6.1.3.tar.bz2/download
2. Rozbalíme jej na vhodné místo.

      $ tar -xvf qwt-6.1.3.tar.bz2
     

3. Ve vzniklém adresáři qwt-6.1.3 upravíme soubor qwtconfig.pri. Zde je potřeba nastavit proměnnou QWT_INSTALL_PREFIX v sekci unix takto:
   QWT_INSTALL_PREFIX = /app
4. Nakonfigurovaná Qwt zabalíme zpět do archivu

      $ tar -cjf qwt-6.1.3_configured.tar.bz2 qwt-6.1.3/
     

Do modulů v manifestu přidáme následující blok. Protože Flatpak - aspoň co jsem dokázal zjistit - nemá přímou podporu pro qmake, pomůžeme si ručně nastavením buildsystemu na simple spuštěním buildu tak, jak bychom to udělali z klasické příkazové řádky.

{
	"name": "qwt",
	"buildsystem": "simple",
	"build-commands": [
		"qmake qwt.pro CONFIG+=release",
		"make -j4",
		"make install"
	],
	"sources": [
		{
			"type": "archive",
			"path": "/home/flatpak/flatpak_PMNG/qwt-6.1.3_configured.tar.bz2"
		}
	],
	"cleanup": [
		"/include",
		"/doc",
		"/features",
		"/plugins"
	]
}

Nalezneme-li v adresáři PMNG_pkg/files/lib knihovnu libLEMNG.so a adresář PMNG_pkg/files/qwt-6.1.3/lib se zkompilovanými Qwt, můžeme si pogratulovat a pokračovat dále.

6. Grand finale

Teď už máme vše, co potřebujeme, abychom sestavili samotný PeakMaster. Stejně jako Qwt se parametry nutné pro sestavení řeší úpravou konfiguračního souboru, tentokrát PeakMasterNG.pri. Protože budeme zdrojáky tahat z gitu, nemůžeme předchozí postup použít. Co s tím?

Nejdříve vytvoříme základní definici modulu, od které se odrazíme. Ta vypadá takto:

{
	"name": "PeakMasterNG",
	"buildsystem": "simple",
	"build-commands": [
		"qmake PeakMasterNG.pro CONFIG+=release CONFIG+=flatpak_build",
		"make -j4",
		"make install"
	],
	"sources": [
		{
			"type": "git",
			"url": "https://github.com/echmet/PeakMasterNG.git",
			"branch": "master"
		}
	]
}

Flatpak umožňuje pracovat i se zdroji ve formě patchů, čehož zde můžeme šikovně využít. Stačí nám stáhnout příslušný konfigurační soubor. Ten zkopírujeme a kopii upravíme tak, že jeho obsah bude tento:

# Path to location where the ECHMETCoreLibs are installed
ECHMET_CORE_LIBS_DIR = "/app"

# Path to location where the LEMNG library is insalled
LEMNG_DIR = "/app"

# Path to where the Qwt toolkit is installed
QWT_DIR = "/app"

include("$$QWT_DIR/features/qwt.prf")

#Do not touch anything below this line!

INCLUDEPATH += "$$ECHMET_CORE_LIBS_DIR/include/ECHMET/CoreLibs"
INCLUDEPATH += "$$LEMNG_DIR/include/ECHMET/LEMNG"
LIBS += -L"$$ECHMET_CORE_LIBS_DIR/lib" -lSysComp -lECHMETShared
LIBS += -L"$$LEMNG_DIR/lib" -lLEMNG
QMAKE_LFLAGS += -Wl,-rpath-link,"$$ECHMET_CORE_LIBS_DIR/lib"

Pomocí

$ diff -u PeakMasterNG.pri PeakMasterNG_mod.pri > PMNG_config.patch

vytvoříme konfigurační patch a umístíme jej do /home/flatpak/flatpak_PMNG/ Do pole sources modulu PeakMasterNG přidáme další objekt s tímto obsahem:

{
	"type": "patch",
	"path": "/home/flatpak/flatpak_PMNG/PMNG_config.patch",
	"strip-components": 0
}

Výchozí hodnota strip-components je 1, což se nám v tomto případě příliš nehodí.

Spustili bychom teď build, PeakMaster by se měl bez problémů zkompilovat a PMNG_pkg/files/bin/ obsahovat soubor PeakMasterNG. K tomu, abychom vytvořili skutečně použitelný balíček nám akle ještě malý kousek cesty zbývá. Hlavičku manifestu je třeba doplnit o následující blok:

"command": "PeakMasterNG",
"finish-args": [
	"--filesystem=host",
	"--socket=x11",
	"--socket=wayland",
	"--socket=pulseaudio",
	"--device=all",
	"--share=ipc"
],

command překvapivě říká, jaký příkaz se při spuštění Flatpakového balíčku provést, my chceme spustit binárku PeakMasterNG. Pole finish-args umožňuje vypnout některá omezení sandboxu. --filesystem=host povolí přístup k celému souborovému systému stroje, kde naše binárka běží. Parametry volby --socket umožní přístup k XServeru, Wayland kompozitoru a PulseAudio serveru hosta. Další nezbytností je --share=ipc, bez čehož by nefungovala sdílená paměť Xek a výkon naší aplikace by dost utrpěl. Chceme-li povolit přístup aspoň k 3D akceleračnímu hardware, musíme ještě uvést --device=dri.

Výsledkem našeho pachtění se můžeme pokochat tak, že program spustíme. Nanečisto spustíme PeakMaster takto:

$ flatpak-builder --run PMNG_pkg/ cz.cuni.natur.echmet.PeakMasterNG.json PeakMasterNG

Pozor na to, že takhle spuštěná binárka se neřídí nastavením snadboxu z finish-args ale parametry, které nastaví flatpak-builder. Ty jsou ve výchozím stavu docela restriktivní a pořádně není přístupný ani souborový systém hosta. Na ověření, že máme sestavené všechny závislosti, knihovny nainstalované na správných místech apod. to ale stačí.

7. Make-up nakonec

Balíček, jak jej máme teď by šel bez problémů zabalit, nainstalovat a spustit, měl by však pár nehezkých nedostatků. Kupříkladu chybějící .desktop záznam by znemožnil jednoduché spuštění programu z nějaké nabídky aplikací. Zde má Flatpak pár specifik, o kterých je nutné vědět.

Protože Flatpakové balíčky jsou identifikovány pomocí app-id, je nutné tomu přispůsobit i příslušný .desktop soubor. Flatpak naštěstí umí tento proces dosti zjednodušit. Náš standardní .desktop záznam vypadá takto:

[Desktop Entry]
Type=Application
Exec=PeakMasterNG
Name=PeakMaster
GenericName=Capillary Zone Electrophoresis simulator
X-KDE-StartupNotify=true
Terminal=false
Categories=Science;Education
Icon=PeakMasterNG

Do hlavičky manifestu přidáme tento blok:

"rename-desktop-file": "PeakMasterNG.desktop"

Samotný .desktop soubor je potřeba nakopírovat na správné místo. To lze zařídit přidáním následujícího řádku do build-commands modulu PeakMasterNG:

"install -D PeakMasterNG.desktop /app/share/applications/PeakMasterNG.desktop"

Podobný trik použijeme i na ikonu aplikace. Hlavičku manifestu obohatíme o

"rename-icon": "PeakMasterNG"

a build-commands o

"install -D res/PeakMaster_icon.png /app/share/icons/hicolor/32/apps/PeakMasterNG.png"

Tady je kruciální dát pamatovat na to, že v rename-icon se uvádí název původního soubru s ikonou bez přípony a že ikonu je při vytváření balíčku nutné nakopírovat na správné místo. Kdybyste se někde spletli, dostanete od flatpak-builderu na konci sestavování balíčku varování. Proběhlo-li vše v pořádku, budou nyní v /home/flatpak/flatpak_PMNG/PMNG_pkg/ v podadresáři export nakopírované soubory PeakMaster.desktop a cz.cuni.natur.echmet.PeakMasterNG.png

8. Jdem to zabalit

I když jsem až dosud hovořil o sestavování balíčku, ve skutečnosti jsme zatím žádný opravdový balíček nevytvořili. Obsah adresáře PMNG_pkg je jen jakýsi prefabrikát, který musíme dotáhnout do konečné podoby. Flatpak umožňuje přímý export do online repozitářů (třeba flathub), tuto možnost jsem ovšem nezkoušel. Předvedu možnost, jakým se vytvoří samostatný soubor, který si uživatel stáhne z webu a pomocí Flatpaku nainstaluje. Je to jednoduché:

$ flatpak build-bundle PMNG PeakMasterNG.flatpak cz.cuni.natur.echmet.PeakMasterNG

kde PMNG je jméno repozitáře, které jsme předávali flatpak-builderu, PeakMasterNG.flatpak jméno výsledného balíčku a cz.cuni.natur.echmet.PeakMasterNG ID aplikace.

Čerstvě sestavený teď už skutečně balíček můžete nainstalovat:

$ flatpak install --bundle PeakMasterNG.flatpak

V aplikačním menu by měla přibýt ikona PeakMasteru. Instalátoru je možné přidat parametr--user, který balíček nainstaluje do ~/.local/share/flatpak.

Příběhy skřípějících zubů aneb že já se do toho ***** pouštěl

Zajisté všichni znáte ten pocit, kdy vaši parádní a samozřejmě perfektně odladěnou aplikaci připravíte pro distribuci, všechno je hotové a připravené, už jste v podstatě jednou nohou ze dveří kanceláře ale stejně vám to nedá, tak tu distribuční verzi přece jen vyzkoušíte. Jen tak, pro ten pocit, že jste všechno prověřili s paranoidní nedůvěřivostí, přesvědčeni, že všechno musí být okay a ono to dopadne takhle:

Ještě více se vyděsíte, když vám dojde, že aplikace havaruje někde v paralelizované části a bez rozumných debugovacích nástrojů to nikdy nevyčmucháte. Co dělat, když potřebujete ladit aplikaci z Flatpakového balíčku?

Flatpakové aplikace je možné debugovat skoro stejně jako všechny jiné. Předpokládáme, že máme kromě runtimu pro danou aplikaci nainstalované i SDK (což na vývojovém stroji určitě máme). Pak lze provést:

$ flatpak run --devel --command=sh cz.cuni.natur.echmet.PeakMasterNG

Místo aplikace samotné se spustí shell, odkud můžeme spustit třeba gdb:

$ gdb /app/bin/PeakMasterNG

Z gdb se ale v tomto případě nedozvíme o moc více, v knihovně MPFR prostě selhal nějaký assert...

Protože tušíme, že jde o problém kdesi v synchronizaci vláken, sáhneme po nástroji helgrind, který je k dispozici také:

$ valgrind --tool=helgrind /app/bin/PeakMasterNG

výstup, obsahující například toto je více než výmluvný:

==5== Possible data race during write of size 8 at 0x6F75010 by thread #10
==5== Locks held: none
==5==    at 0x6D36268: mpfr_set_d (in /usr/lib/libmpfr.so.4.1.4)
==5==    by 0x6F9A727: ??? (in /app/lib/libCAES.so.0.2)
==5==    by 0x6F89D55: calculateFirstConcentrationDerivatives_prepared (in /app/lib/libCAES.so.0.2)
==5==    by 0x53B7342: ??? (in /app/lib/libLEMNG.so.0.3)
==5==    by 0x53BF318: std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) (in /app/lib/libLEMNG.so.0.3)
==5==    by 0x382020EE78: ??? (in /usr/lib/libpthread-2.24.so)
==5==    by 0x53B68C9: ??? (in /app/lib/libLEMNG.so.0.3)
==5==    by 0x3820AB7F6E: ??? (in /usr/lib/libstdc++.so.6.0.22)
==5==    by 0x3820207443: ??? (in /usr/lib/libpthread-2.24.so)
==5==    by 0x381FAE827E: clone (in /usr/lib/libc-2.24.so)
==5== 
==5== This conflicts with a previous read of size 8 by thread #9
==5== Locks held: none
==5==    at 0x6D2C984: mpfr_mul (in /usr/lib/libmpfr.so.4.1.4)
==5==    by 0x6F8CF41: ??? (in /app/lib/libCAES.so.0.2)
==5==    by 0x6F8DE16: ??? (in /app/lib/libCAES.so.0.2)
==5==    by 0x6F8BB74: ??? (in /app/lib/libCAES.so.0.2)
==5==    by 0x6F89DB7: calculateFirstConcentrationDerivatives_prepared (in /app/lib/libCAES.so.0.2)
==5==    by 0x53B7342: ??? (in /app/lib/libLEMNG.so.0.3)
==5==    by 0x53BF318: std::__future_base::_State_baseV2::_M_do_set(std::function<std::unique_ptr<std::__future_base::_Result_base, std::__future_base::_Result_base::_Deleter> ()>*, bool*) (in /app/lib/libLEMNG.so.0.3)
==5==    by 0x382020EE78: ??? (in /usr/lib/libpthread-2.24.so)
==5==  Address 0x6f75010 is 0 bytes inside data symbol "__gmpfr_emin"

Knihovna MPFR by měla být thread-safe, pokud to daná platforma a použitý překladač umožňují. Jako thread-unsafe se MPFR přeloží pouze tehdy, nedovolí-li to použité prostředí nebo je to ručně zakázáno v konfiguraci. Výstup helgrindu napovídá, že MPFR dodáváná v runtime org.kde.Platform thread-safe nejspíš není. Způsobů, jak to ověřit se nabízí několik. Můžeme například přidat vlastní build knihovny MPFR jako další modul. To uděláme tak, že úplně na začátek pole modules vložíme

{
	"name": "mpfr",
	"buildsystem": "autotools",
	"config-opts": [
		"--enable-thread-safe",
		"--disable-static"
	],
	"sources": [
		{
			"type": "archive",
			"url": "http://www.mpfr.org/mpfr-current/mpfr-4.0.1.tar.xz",
			"sha256": "67874a60826303ee2fb6affc6dc0ddd3e749e9bfcb4c8655e3953d0458a6e16e"
		}
	],
	"cleanup": [
		"/include",
		"/share"
	]
}

Význam jednotlivých položek už je předpokládám jasný. Projdeme-li výstup helgrindu teď, zjistíme, že žádné synchronizační problémy v našem kódu už nehlásí a program nepadá! (Pozor na to, že helgrind dodávaný s Flatpakovými SDK je trochu problémový a občas spadne sám o sobě.) Jednou ze zvláštností, na kterou jsem při testování Flatpaku narazil bylo, že některé knihovny jsou očividně přeložené i s asserty. Pokud jste zapomněli v kódu nějakou hloupou chybu, můžete o nějaký takový assert zakopnout.

Done!

Protože jde o první projekt, který hodlám pro Linux distribuovat pomocí Flatpaku, těžko můžu na závěr nabídnout nějaké dlouhodobější zkušenosti nebo doporučení. Můžu říct pouze tolik, že mi celý proces přišel docela elegantní. Vzhledem k tomu, jak flexibilní musí flatpak-builder být se to o moc jednodušeji udělat nejspíš nedá. Jak moc se mi Flatpak osvědčí v praxi ukáže až čas...

Úplný finální manifest:

{
	"app-id": "cz.cuni.natur.echmet.PeakMasterNG",
	"runtime": "org.kde.Platform",
	"runtime-version": "5.9",
	"sdk": "org.kde.Sdk",

	"command": "PeakMasterNG",
	"finish-args": [
		"--filesystem=host",
		"--socket=x11",
		"--socket=wayland",
		"--socket=pulseaudio",
		"--device=all",
		"--share=ipc"
	],

	"rename-desktop-file": "PeakMasterNG.desktop",
	"rename-icon": "PeakMasterNG",

	"modules": [
		{
			"name": "mpfr",
			"buildsystem": "autotools",
			"config-opts": [
				"--enable-thread-safe",
				"--disable-static"
			],
			"sources": [
				{
					"type": "archive",
					"url": "http://www.mpfr.org/mpfr-current/mpfr-4.0.1.tar.xz",
					"sha256": "67874a60826303ee2fb6affc6dc0ddd3e749e9bfcb4c8655e3953d0458a6e16e"
				}
			],
			"cleanup": [
				"/include",
				"/share"
			]
		},
		{
			"name": "eigen",
			"buildsystem": "simple",
			"build-commands": [
				"mkdir -p /app/Eigen",
				"cp -r Eigen /app/Eigen",
				"cp -r unsupported /app/Eigen"
			],
			"sources": [
				{
					"type": "archive",
					"url": "http://bitbucket.org/eigen/eigen/get/3.3.4.tar.bz2",
					"sha256": "dd254beb0bafc695d0f62ae1a222ff85b52dbaa3a16f76e781dce22d0d20a4a6"
				}
			],
			"cleanup": [
				"/Eigen"
			]
		},
		{
			"name": "CoreLibs",
			"buildsystem": "cmake",
			"config-opts": [
				"-DCMAKE_BUILD_TYPE=Release",
				"-DEIGEN_INCLUDE_DIR=/app/Eigen",
				"-DCMAKE_INSTALL_PREFIX=/app",
				"-DCMAKE_CXX_FLAGS=-g"
			],
			"sources": [
				{
					"type": "git",
					"url": "https://github.com/echmet/ECHMETCoreLibs.git",
					"branch": "master"
				}
			],
			"cleanup": [
				"/include"
			]
		},
		{
			"name": "LEMNG",
			"buildsystem": "cmake",
			"config-opts": [
				"-DCMAKE_BUILD_TYPE=Release",
				"-DEIGEN_INCLUDE_DIR=/app/Eigen",
				"-DECHMET_CORE_LIBS_DIR=/app",
				"-DCMAKE_INSTALL_PREFIX=/app",
				"-DCMAKE_CXX_FLAGS=-g"
			],
			"sources": [
				{
					"type": "git",
					"url": "https://github.com/echmet/LEMNG.git",
					"branch": "master"
				}
			],
			"cleanup": [
				"/include"
			]
		},
		{
			"name": "qwt",
			"buildsystem": "simple",
			"build-commands": [
				"qmake qwt.pro CONFIG+=release",
				"make -j4",
				"make install"
			],
			"sources": [
				{
					"type": "archive",
					"path": "/home/flatpak/flatpak_PMNG/qwt-6.1.3_configured.tar.bz2"
				}
			],
			"cleanup": [
				"/include",
				"/doc",
				"/features",
				"/plugins"
			]
		},
		{
			"name": "PeakMasterNG",
			"buildsystem": "simple",
			"build-commands": [
				"qmake PeakMasterNG.pro CONFIG+=release CONFIG+=flatpak_build",
				"make -j4",
				"make install",
				"install -D PeakMasterNG.desktop /app/share/applications/PeakMasterNG.desktop",
				"install -D res/PeakMaster_icon.png /app/share/icons/hicolor/32/apps/PeakMasterNG.png"
			],
			"sources": [
				{
					"type": "git",
					"url": "https://github.com/echmet/PeakMasterNG.git",
					"branch": "master"
				},
				{
					"type": "patch",
					"path": "/home/flatpak/flatpak_PMNG/PMNG_config.patch",
					"strip-components": 0
				}
			]
		}
	]
}

       

Komentáře

[Jardik]

Tak kvuli qt aplikaci je potreba kde sdk, tj mnohem vetsi moloch nez je skutecne treba. Pak stejne musis bundlovat svoje verze knihoven, protoze ty v sdk padaj. No a pak kazda aplikace pro jinou verzi sdk ... co kdyz autor apku nezaktualizuje, to budu muset mit sdk plnebezpecnostnich a funkcionalnich chyb? No potes ...

[MadCatX]

Na tu molochoviost runtimů se můžeš dívat různě. Kdyby existovaly nějaké menší varianty (qt, qt-noqtquick, qt-minimal apod.), velmi rychle by ses dostal do stavu, kdy by každá aplikace chtěla vlastní runtime. To by byl ve výsledku větší zmatek než mít jeden masivní runtime, který pokryje závislosti daleko více aplikací. V rámci možností binární kompatibility by měly dostávat aktualizace i ty runtimy, takže bezpečnostní aktualizace se k uživatelům (snad) dostanou. To je velká výhoda oproti statickým buildům. Nějaký abandonware se stane rizikem dříve či později tak jako tak. Ke snížení bezpečnostních rizik má Flatpak sandbox.

[Rosta]

Takze zhorsime bezpecnost starymi zavislostmi s argumentem, ze sandbox ji zase zvysi. :D A ja si naivne myslel, ze ta izolace sandboxu je dalsi dodatecna uroven zabezpeceni... :)

[MadCatX]

Takhle ten argument ale přece nezní. Sandbox je tam hlavně proto, aby bylo možné relativně bezpečně instalovat aplikace z nedůvěryhodných zdrojů. Navíc závislosti staré být nemusí, pokud bude uživatel udržovat aktuální ten runtime. Ideální to není ale v rámci možných kompromisů mi to přijde přijatelné.

[Petr]

Tomuhle nerozumim. Pokud moznosti aplikace v ramci sandboxu definuji primo v tom flatpakovym balicku, jak to zvysi bezpecnosti spousteni z neznamych zdroju? Jako malware creator bych asi nastavil minimalni omezeni pro sandbox, nebo se pletu v necem a muzu nejakym snadnym zpusobem definovat nekde ze pro flatpak aplikaze ze zdroje x pouzij maximalni bezpecnost sandboxu?

[MadCatX]

Nastavení sandboxu se dají nastavit buď jednorázově (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.

[Ravise]

Což stejně bude muset dělat ten na konci řetězu a pro každý flatpak zvlášť. Spíš bych si představoval nějaké varování, že "App chce přistupovat k ... [povolit jednou] [povolit vždy] [zakázat]"

[Petr]

Bfu to delat nebude, povoli vse...

[Luboš Doležel (Doli)]

Což o to, kompletní Qt runtime by mi nevadil, ale řekl bych, že většina Qt aplikací fakt KDE runtime nepotřebuje. Navíc existují oficiální buildy Qt, které by stačilo převést do formátu Flatpaku.

[RB]

Lze použít FreeDesktop runtime, který je fakt malý. Nicméně pak by si člověk musel bundlovat Qt. Jako nikdo nebrání tomu, aby se udělal malý Qt runtime. Flatpak podporuje také rozšíření runtimů, takže ten KDE runtime by šel udělat menší a třeba KDE Frameworks by se dalo dát do rozšíření, o jehož instalaci by si aplikace mohla říct, pokud by něco z něj potřebovala.

[Want]

To by jeden blil. Ještě že existuje mnohem jednodušší a efektivnější způsob jak vyrobit standardní binární balík: Použiju overlay, normálně to nainstaluju, pak z ramdisku vykopíruji obsah který chci zabalit, vyhodím co tam nechci. V případě nutnosti dopíšu postinstalační skript, přidám soubor s popisem balíku a použiju standardní distribuční nástroj k vytvoření binárního balíku.

[dumblob]

To preci jiz dlouho existuje plne automatizovane. A tesi se velke oblibe:

https://github.com/jordansissel/fpm

[MadCatX]

Podobně by se dalo použít i třeba OBS od SUSE, které má teda menší rozsah podporovaných formátů. Problém s distribucí nativních balíčků pro různá distra je ten, že je třeba je udržovat a v případě potřeby přebuildovat vůči novým (či naopak starým) závislostem. Pokud není v týmu aspoň jeden člověk, co by aplikaci X na distru Y aktivně používal, musí to IMHO dřív nebo později skončit tím, že se aspoň jeden balíček rozbije.

[smazáno]

.. a uplne stejne ti tvuj balicek rozbije update "runtime"

[MadCatX]

Jak? Pokud ty runtimy nebude spravovat nějaký pitomec, měla by být jedna řada runtimu pořád binárně kompatibilní.

[smazáno]

uplne to stejne plati o distrech

[MadCatX]

I o distrech jako Fedora, Debian-(unstable,testing), Arch etc.?

[smazáno]

naopak, i "stable" distra co slibuji ABI kompatibilitu se z "nepochopitelnych" duvodu rozbijeji

a to stejne se bude dit s temi runtimes

[MadCatX]

Promiň ale citation needed.

[smazáno]

Jasne, napriklad par dnu stare kompletni rozbiti kernel driveru v LTS ubuntu ... https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1750937

[MadCatX]

Kernel ABI != userspace ABI a já se hlavně ptal na případy, kdy něco rozbil update flatpakového runtime.

[smazáno]

Kernel ABI != userspace ABI

Ve 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?).

[smazáno]

treba https://github.com/flatpak/flatpak/issues/1359 ?

[smazáno]

https://github.com/flatpak/flatpak/issues/1276 taky dobry

[RB]

To je pěkné, ale když se něco takového stane, tak ten problém řeším s jedním runtimem. Ne s RHELem, SLESem, Debianem, Ubuntu LTS... a to jmenuju jen distra s dlouhou podporou. Ano, i runtime ve Flatpaku může rozbít ABI, ale rozdíl oproti distribuci přes balíčky v distribucích je v tom, že mám jednu platformu, pro kterou vyvíjím a proti které musím testovat, a pořád můžu zasáhnout desítky distribucí.

[smazáno]

To zni rozumne, jenze pokud kvuli Flatpaku prestanes RHEL, Suse, Debian a Ubuntu podporovat, tak o hodne uzivatelu/zakazniku prijdes.

[MadCatX]

Na mainstream distrech je Flatpak k dispozici taky, o žádné uživatele v principu přijít nemusíš.

[smazáno]

Treba ubuntu 14.04 je stale podporovane, ale flatpak pro nej neni.

Navic dost uzivatelum, zvlast na linuxu, bude ten bloat a velice problemove integrovani do systemu (krome temat, fontu, napr. firemni CA) vadit.

[MadCatX]

Záleží na aplikaci. Integrace do systému mi nepřijde až tak špatná - aspoň z pohledu BFUčka - a předpokládám, že každý vývojár si udělá analýzu přínosů a omezení. Kdybych měl k ruce člověka, co by se o ten packaging na Linux staral, nativní balíčky pro pár nejprofláklejších dister bych asi připravil. Protože musím dělat všechno od návrhu, výpočetních knihoven až po UI a testování sám a celé to je v podstatě takový vedlejší produkt, nemám na mrcasení se s každou libBrokenDependency.so.66.6 čas a sáhnu tedy po něčem jako Flatpak. Tak jako se vším je o to o nalezení vhodného kompromisu.

[smazáno]

To vcelku souhlasim, je to vlastne o neco lepsi (a v necem horsi) nez vytvorit tarball, ktery si bude tahat vsechny zavislosti se sebou. Pokud by byl flatpak takto propagovan, tak je vse v poradku, ale "the future of application distribution"? To nemuzou myslet vazne prece...

Me hodne zajima ta integrace - co tam funguje prosimte? Zatim jsem se dozvedel, ze si to umi nekdy precist jake ma system (nebo uzivatel?) nastavene GTK tema a nainstalovat, pokud je podporovane, tema se stejnym nazvem.

Clanek je samozrejme super. :)

[MadCatX]

Nějak marketovat to přece musí;)

Jak moc dobře se flatpakové aplikace integrují do systému můžu vyzkoušet pořádněji, zatím jsem se omezil na „dá se to jednoduše zbuildit, vím jak na to a zdá se to funkční”. Minimálně adaptace na systémový GUI make-up vypadá OK. Možná by z toho mohl být další zápisek...

[smazáno]

• pouziva se ve flatpaku stejny font jako v systemu?
• .. kdyz zmenim nastaveni fontu v systemu, zmeni se bez resetu aplikace i ve flatpak aplikacich (pripadne aspon po resetu)?
• .. co kdyz font, ktery pouzivam v systemu, neni ve flatpaku
• nastaveni renderovani fontu - pro zacatek vypnuti antialiasingu
• pouziva flatpak stejne tema jako v systemu?
• .. kdyz zmenim tema v systemu, zmeni se bez resetu aplikace i ve flatpak aplikacich (pripadne aspon po resetu)?
• .. co kdyz tema, ktery pouzivam v systemu, neni ve flatpaku (!!)
• .. jak se flatpak chova pokud dva uzivatele na stejnem systemu pouzivaji ruzna temata?
• .. ^^ minimalne pro GTK a QT
• integrace libGL a knihoven k driverum .. Je hw akcelerace oficialne podporovana pro flatpak aplikace? Co kdyz vyhodim ze systemu nvidia GPU a vymenim za AMD? Resp. vzdyt je potreba aby knihovny a drivery byly ve stejne verzi(!!) .. jak se tohle resi?
• budou flatpak aplikace respektovat moje systemove nastaveni CJK IME ??
• Firemni CA pridana v /etc/ssl/certs a nastaveni /etc/ca-cerficates.conf
• Bude flatpak respektovat nastaveni proxy v systemu?
• Pokud aplikace potrebuje poslouchat na nejakem portu? To se resi predpokladam pres DNAT? I na ipv6?
• Pokud by byl soucasti aplikace treba skriptik do /etc/cron.daily nebo systemd timer, kam se nainstaluje?
• Pokud se ma aplikace spoustet po startu/ovladat pres init skripty, jak je toto vyreseno?

[MadCatX]

Tohle zní jako rozumné požadavky na dostatečně integrovanou aplikaci. Zkusím si někdy během příštích pár týdnů udělat čas a v rámci možností to vyzkoušet. Co se ovladačů GPU týče, ty pokud vím nejsou součástí žádného flatpakového runtimu a vždy se použijí ty systémové, proto je taky přístup k 3D hardwaru nutné odsandboxovat přes --device=dri (doufám, že nekecám).

[smazáno]

Soucasti ovladacu jsou krome modulu do jadra i knihovny jako libGL. Knihovny a driver v jadre musi byt ve stejne verze.

[MadCatX]

Však jo. Pokud vím, Mesa ani žádná její část ve Flatpakových runtimech není.

[smazáno]

Ja se prave divam ze se tam snazi zabalickovat vsechny verze knihoven k nvidia driverum.

[AsciiWolf]

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.

[AsciiWolf]

Tedy, abych byl přesnější - spouštění po přihlášení (přes desktop soubor v ~/.config/autostart/) není problém; spouštění a ovládání přes init scripty/systemd unity by teoreticky šlo, ale pro takové věci prostě Flatpak není určen. Je určen pro uživatelské (primárně GUI) aplikace, ne pro démony.

[smazáno]

GUI aplikace, jejiz soucasti je i nejaky demon, ktery by se mel poustet pri bootu/loginu, me uplne scifi neprijde - typicky node a penezenka v jednom pro ruzne coiny. Nakonec, systemd to podporuje.

[AsciiWolf]

Tohle by mělo jít přes xdg portály/dbus. Nicméně ten démon musí být distribuovaný samostatně, ne jako součást Flatpak balíčku.

[Petr]

Jak je to s bezpecnosti flatpaku ve smyslu treba digitalniho podpisu?

[MadCatX]

Podepisování pomocí GPG klíčů by mělo být podporované ale nezkoušel jsem to.

[Petr]

A to jsem si rikal, ze bastleni rpm nebo deb je nekdy pakarna... chapu vyhodu flatpaku, ale taky vidim jaky bordel to nese sebou. Kdyz to dovedu do extremu, tak diky nejake prilozene ssl library misto pouziti sdilene mam v systemu diru dokud ji autor flatpak aplikace nefixne. 10 autoru, 10 dir. zatimco u rpm proste aktualizuji fixnutou ssl library a 10 aplikaci patrne bude fungovat dale.

[Adolf Kernel]

rovno nech sa distribuuju komplet paravirtualizacne kontajnery - k tomu ten flatpack speje...

[RB]

No, díru v systému mít nebudeš. Budeš ji mít v té konkrétní sandboxované aplikaci. Aplikace, které jsou "dobří občani open-source ekosystému", používají standardní knihovny, které jsou v runtimu (včetně té tebou zmiňované SSL). Runtimy jsou sdílené a udržované větším projektem, takže podobné distribucím. Aplikace, typicky ty 3rd party, které si bundlují prakticky všechno, už to dávno dělají v RPM a DEB a popravdě, raději na takové aplikace použiju Flatpak, kde jim nemusím dávat během instalace práva roota, neinstalují mi soubory libovolně do systému a neběží mi ve stejném namespacu jako zbytek systému.

[trekker.dk]

Takže místo runtime z distra bude potřeba hlídat kompatibilitu se sdíleným runtime. A nebo si ten runtime balit k aplikaci. To první má stejný problém jako vývoj proti distru (= flatpak je zbytečný), to druhé má bezpečnostní problémy (= flatpak je nebezpečný)

[MadCatX]

Jenomže dister jsou stovky, sdílený flatpakový runtime jen jeden. Proti tomu se hlídá kompatibilita daleko snáze.

[smazáno]

To urcite usetri praci ... ale nebude pak muset mit uzivatel nainstalovano 10 ruznych runtime (z toho 9 neudrzovanych a deravych), protoze ruzne aplikace budou vyzadovat runtime ruznych verzich?

[MadCatX]

Zodpovědný vývojář bude doufám vyvíjet pro nějakému z „oficiálních“ runtimů s dobrou podporou. Podobné peklo s potenciální záplavou exotických a nepodporovaných závislostí může snadno vzniknout např. na Archu instalováním balíčků z AURu. Jde IMHO o problém „kulturní“ který nemá vyloženě technické řešení...

[trekker.dk]

Samozřejmě že ne, s příchodem flatpaku prasata vývojáři s nevelkým rozhledem procitnou, přestanou vyvíjet bez ohledu na okolní svět, zavládne všeobecný mír a ráj na zemi. No nic, zpátky do reality...

[MadCatX]

I kdyby to byla pravda, klidně ať se tak stane. Vzhledem k tomu, jak je Flatpak od zbytku systému izolovaný ti libolovný bazmek nemůže příliš ublížit. Mít nainstalovaných několik runtimů najednou není šikovné ale v mometně, kdy by mi to začalo vadit může beztrestně odinstalovat, co nepotřebuji nebo klidně wipenout celý /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.

[Grunt]

Nejsem ani Archista ani AURista, ale zrovna AUR se mi docela líbí a použil bych ho jako protipříklad k Flatpaku. Nedá se natvrdo zalinkovat libLegacyB (přecejen je to kompilace) oproti WeirdAppA? Když si instaluju v binárních distrech věci ručně, jednoduše si připravím adresář /opt/WeirdAppA a svoje verze knihoven si do ní zakompiluju a pak nahardlinkuju proti samotné aplikaci. Něco takového v Archu možné není?

[MadCatX]

V tom případě by sestavení závislostí a samotné aplikace musel řešit PKGBUILD oné WeirdAppA a dále zde máme opět problém statického linkování a argumentu, že všechny knihovny by měly být sdílené. Za třetí i ta libLegacyB může mít nějakou system-wide závislost, která by se mohla časem rozbít a vyžadovat rebuild.

Pokud si něco sestavuješ ručně včetně závislostí, děláš vlastně úplně totéž co ve finále Flatpak, akorát bez sandboxu a centralizované správy. Na tom samozřejmě není nic špatného a bude se to (možná) o něco lépe integrovat se zbytkem systému ale rozhodně to není instalační postup, který můžeš chtít po BFU.

[Kate]

Nejen bez sandboxu a centralizované správy, ale pořád přijde o updaty runtime, které flatpak zajistit umí.

[trekker.dk]

Jo, protože stejné knihovněy převzaté ze stejných zdrojáků přibližně ve stejné době se od sebe v různých distribucích naprosto zásadně liší tak, že v tom je problém a prostě to uhlídat nejde, což je důvod, proč vznikl flatpak. Jasně...

[MadCatX]

Tohle přece není pravda. Ubuntu 16.04 bude mít o dost jiné verze knihoven než třeba RHEL 7, Fedora 27 nebo aktuální Arch. Některé distribuce si nedělají velkou hlavu klidně i s major aktualizací nějaké knihovny v rámci jedné verze, jiné se to snaží hlídat. Pokud nemáš člověka, co by releasy na Linux spravoval, nemáš šanci podporovat víc než hrstku distribucí a i tak to bude vyžadovat pravidelnou kontrolu, že je všechno stále OK.

[trekker.dk]

Přičemž ty jiné verze se od sebe budou lišit tak zásadně, že to vlastně bude úplně jiná knihovna...

[MadCatX]

O to přece nejde. I kdyby API zůstalo stejné, pořád se může změnit ABI což může paradoxně být i horší problém. Jen ABI MPFR se za poslední rok změnilo asi 3x. Zkus podobné změny uhlídat ručně pro všechny závislosti na všech distrech, které chceš nativně podporovat a vždy včas poskytnout aktualizované balíky.

[Adolf Kernel]

v jednoduchosti je krása. flatpak nevyzera byt jednoduchy...

[Albert Einstein]

Everything should be made as simple as possible, but no simpler.

[Albert Einstein]

Věci mají být jednoduché jak jen to jde. Ale ne jednodušší.

[smazáno]

Uz flatpak respektuje systemove fonty (vcetne nastaveni renderovani) a temata?

[MadCatX]

Systémová témata ano, nastavení renderování těžko říct kvůli rozdílům v knihovně freetype2.

[smazáno]

Ty systemova temata furt tim hackem ze si musis do flatpaku (runtimu?) rucne nainstalovat a nastavit to ktere pouzivas (pokud pro flatpak vubec je)? Tzn. integrace jako takova zadna?

Pokud se pouziva uzivatelska/systemova konfigurace ... jak se resi rozdily v konfiguraci mezi ruznyma verzema toho tematu (a to i takove ze s configem z jine verze muze padat) ?

[MadCatX]

Mně to fungovalo úplně bezúdržbově na všech čtyřech systémech, kde jsem to zkoušel. Možná jsi to z textu článku nezaregistroval ale já nejsem žádný flatpakový evangelista ani guru. Přišlo mi zajímavé podělit se o své zkušenosti a případně to konfrontovat s jinými možnostmi. Pochopil jsem, že se ti koncept flatpaku nelíbí, okay, jak bys to tedy řešil ty?

[smazáno]

A pouzivas vlastni temata (nebo vzdy vychozi systemove)?

Zminuju/ptam se na konkretni problemy - az vsechny ty problemy, ktere sebou flatpak prinasi, vyresi, tak to muze byt zajimava technologie.

[smazáno]

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.

[RB]

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. Minimálně, co se týče GTK, tak jsou tam ta nejrozšířenější. Pokud ho má uživatel nastavené v systému, automaticky se nainstaluje pro Flatpak a uživatel nemusí nic dělat. Libovolně témata ze systému to přebírat nebude, protože v runtimu je zpravidla jiná verze GTK než v systému a nikdo nezaručí, že to téma ze systému bude bezproblémově fungovat i s GTK z runtimu.

[smazáno]

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.

[smazáno]

Ale jo, to ze se to aktualni tema nacte z konfigurace systemu a automaticky nainstaluje a nastavi je fajn. Tohle se deje vlastne kdy?

[smazáno]

freetype2 ti bude navic se stejnym configem v ruznych verzich renderovat znatelne jinak

[PetrHL]

Díky za sdílení zkušenosti.

Mám aplikaci napsanou ve FreePascalu/Lazarusu a chtěl jsem ji zkusit distribuovat jako flatpack. Rychle mě to přešlo, bylo by to šíleně komplikované. Objevil jsem počin jménem AppImage. Pro mne, jako autora aplikace, mnohem pohodlnější a předvídatelnější.

[Luboš Doležel (Doli)]

Navíc mám pocit, že AppImage je na rozdíl od Flatpaku opravdu používaný. Zatímco Flatpak jsem ještě nikdy neviděl, aplikací v AppImage mám stažených hned několik.

[kolega]

Jestli jsi se s flatpakem nesetkal, tak jdi na flathub

[Ravise]

Když to, co hledám, není v systémových repozitářích, jdu hledat na stránky toho kterého projektu a jdu tam, kam mě pošlou.

Náš administrátor shledal tento komentář závadným.

NSFW píseň skupiny Masturbace

Zobrazit komentář

[AsciiWolf]

Flatpak je běžně používaný např. na Linux Mintu či Fedoře a některé distribuce, např. Endless OS či Fedora Atomic Workstation, jsou na něm dokonce postaveny. Další distribuce se pomalu přidávají k jeho podpoře ve výchozí instalaci (krom Ubuntu, které má svůj vlastní Snap).

[Rezza]

Zase u AppImage je to takove "na kolene" - uz jsem zazil takove, kde jela az xta verze po nahlaseni bugu, protoze autor zabundloval minimum knihoven, takze tu chybelo tohle, tu bylo tohle v jine verzi atd. U Flatpaku by tohle mel resit runtime.

[RB]

Přesně, u AppImage si autor může volně linkovat mimo ten bundle, což je cesta do pekel. Bude to lavírovat mezi: funguje to na systému autora, funguje to na systému lidí, kteří hlásí bugy atd. Nějaká záruka portovatelnosti tam není.

[smazáno]

Za to kdyz se aplikace bunduluje s kompletnim OS (to rovnou muzou bundlovat i s vlastnim hardware), tak to je uplne ale uplne bezproblemovy ....

[RB]

Nic není nikdy úplně bezproblémové, ale jinak ano, Flatpak je v tomto ohledu výrazně méně problémový než AppImage.

[smazáno]

A kdybyste bundlovali s kazdou aplikaci i vlastni hardware tak je to uplne bezproblemovy :P.

[Rezza]

Neni - takovych Hw/SW kombinaci zname dost a stejne nefunguji :). Ale jde o to, kde mame tu hranici, kde je to jeste akceptovatelne a kde uz ne.

[smazáno]

Aplikace, kde mi nefunguje klavesnice (resp. IME), protoze si sebou bundluje cely OS, je urcite za tou hranici.

Na druhou stranu, kdyz gnome "vyvojari" maji potrebuju rozbijet ABI i API kazdych 6 mesicu, tak si aplikace cely gnome sebou bundlovat musi.

[ehm]

Článek je pěkný (a díky za něj), ta technologie už tolik ne. Zatím rozmýšlím, jestli je za tím víc konzervativnost, nebo racionální důvody. V současných balíčkovacích systémech vidím nedostatky, ale nevím, jestli tohle bude celkově vzato lepší.

Mimochodem, to klonování masteru mě fakt děsí. Nedá se tam naspecifikovat alespoň ID posledního commitu? U souboru to chce checksum, tak proč u Gitu se to spokojí s názvem větve? Takhle je to naprosto nezreplikovatelné, každý, kdo to vybuildí, může dostat úplně jiný program.

[MadCatX]

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.

Co se klonování z gitu týče, jde uvést branch, tag i konkrétní commit, který se má použít.

[trevor12]

tento prispevek by si zaslouzil placeny clanek na root.cz

[Petr]

Rekneme si to na rovinu, flatpak umoznuje bez nejake vyrazneho testovani dostat aplikaci na xx dister misto 2-3 s testovanim. Autor usetri cas, ale tak nejak to shazuje unix pristup ze knihovny jsou sdilene a aplikace pouzivaji to co uz je v systemu misto aby si tahali sebou vsechen bordel. Flatpak mi pripomina takovy zip pro windows ve kterem jsou vsechny dllka a aplikace, bez ohledu na to ze vsechny dllka mam uz v systemu a v 10ti dalsich adresarich ruznych aplikaci.

[Agent]

Já být vývojář distribuující si sám své výtvory do světa, tak udělám balíčky na 2 max. 3 nejpoužívanější balíčkovací systémy a ostatní buď ať se přizpůsobí a začnou používat jeden z těch balíčkovačů, nebo ať si trhnou. Variabilita a možnost výběru může být dobrá věc, ale co je moc, je moc.

[RB]

A aby to fungovalo na rozumném počtu distribucí, tak budeš bundlovat jak o život. Bez sandboxu, ve stejném namespacu...

[Petr]

Nic ve zlym, ale pokud je cely flatpak postaveny na tom, ze v manifestu jako autor aplikace urcis omezeni (rozumi se malware se nebude omezovat) anebo cekas ze si uzivatel udela nejaky override tak ta security je nastavena spatne.

[RB]

To, že to tak funguje nyní a sandboxing není vynucovaný, neznamená, že to tak bude fungovat i v budoucnu. Běží to v kontejneru, má to definované API na nejběžnější komunikaci mimo sandbox, takže základy pro účinný sandboxing na rozdíl klasických balíčků tam jsou.

[Petr]

Naprosty souhlas. Misto toho aby se linuxovy svet nejak zjednocoval, tak open source zpusobuje to, ze nekomu se nelibi neco, vznikne dalsi distribuce. A pak tady mame urpmi, rpm, apt, flatpaka miliony dalsich balickovacu ktere se obcas v nicem nelisi, obcas se zasadne lisi. Delat komercni soft pro linux? Rpm, deb, pkg a ostatni me nezajima. Delat soft jako one man show? Flatpak.

[RB]

Nevím, jestli to je Unix přístup, protože ve světě unixů (např. BSD) se jedou aplikační bundly už drahně let.

[Petr]

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.

[Vantomas]

httpd běží asi tak na 100 milionů zařízení, kdežto tady jeho PeakMaster asi tak na 100 zařízeních? To je pak jasný, že se maintaineří jen hrnou. A pro každou distribuci celé zástupy!

Osobně u obskurní aplikace dám radši přednost Flatpaku, než vlastní kompilaci ze zdrojáků. To je k systému ještě méně čistější a obecně vzato i bezpečnější.

[ehm]

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í.

[dumblob]

Některé z těchto myšlenek jsou implementovány v nejpokročilejším (a přitom jednoduchém) mně známém balíčkovacím systému GNU Guix.

[Petr]

A nekdo ho pouziva?

[dumblob]

No jistě. To by jinak v těch repozitářích nebyly tisíce aktuálních (!) balíčků (přes 7100 jich je aktuálně zahrnuto v continuous integration).

Jinak Guix můžete používat i v jakémkoliv jiném distru - funguje všude (paralelně k distro-specific "nativnímu" balíčkovači). Docela se hodí, že Guix umí instalovat jakékoliv množství různých verzí téhož, což právě většina nativních balíčkovačů absolutně nezvládá.

[Petr]

Dekuji, podivam se na to..

[Grunt]

Jen tak pro zajímavost:

     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?

[MadCatX]

Flatpakovový balíček má cca 1.5 MB, Release verze binárky PM cca 800 kB (bez závislostí). Zbytek toho příspěvku nechápu. PM je GUI frontend pro výpočetní engine a všechno má nějaké závislosti, které se logicky musí nainstalovat. AppStoru? Kdyby bylo možné PM distribuovat přímo třeba skrze flathub, fungovalo by to skoro jako nějaký AppStore. Přiznám se, že mi vůbec není jasné, co jsi chtěl říct.

[chrono]

Chcel povedať to, že kvôli megabajtovej aplikácii sa nainštalovali desiatky megabajtov rôznych knižníc (navyše, ktorých väčšinu už aj tak bude mať, v aktuálnej a udržiavanej verzii, nainštalovanú v systéme).

[Grunt]

ECHMETCoreLibs a LEMNG jsou nezbytné součásti vlastní grafické aplikace a vzhledem k tomu že jsou vyvíjený tamtéž jako samotná grafická aplikace, nejspíš nebudou běžnou součástí žádného běžného systému a Grunt to prostě zapomněl přidat do výčtu. Ale samozřejmě to neznamená že tahle situace nemůže nastat.

[lizbee]

love this site so much! electrolysis memphis