Jak už jsem tady psal, před časem jsem přešel na Silverblue, kde zkouším myšlenku neměnného systému, takže všechny desktopové aplikace provozuji ve Flatpaku. Z aplikací, které používám, mi na Flathubu chyběl Evolution a Datovka. Evolution jsem tam dostal asi před měsícem Datovku nyní.

Základ manifestu pro flatpak Datovky jsem napsal na LinuxDays během našeho workshopu na vytváření flatpaků. Má relativně málo závislostí. Kromě samotné Datovky musím sestavovat jen libxml2 a libisds. O zbytek (OpenSSL, Qt a jeho moduly) se postará KDE runtime.

Poprvé jsem taky vyzkoušel napsat manifest v YAMLu místo v JSONu. Píše se to jednodušeji, přijde mi to přehlednější. Jen tedy debuggování chyb v syntaxi je oproti JSONu opravdu opruz. Zatímco u JSONu mi Flatpak vrátí přesný řádek a znak chyby, u YAMLu jen neurčitá chybová hlášení a některé chyby v syntaxi přešel úplně. Takže z mé zkušenosti je YAML pro psaní manifestů dobrý do té doby, než v něm musíte hledat nějaké chyby 🙂

Napsat manifest, aby se aplikace sestavila a spustila, byla otázka asi půl hodiny. Ta skutečná zábava přichází v momentě, kdy chcete, aby aplikace ve Flatpaku běžela dobře, aby vše fungovalo, aby neměla otevřený přístup do hosta.

Prvním problémem bylo, že Datovka nebyla schopná ukládat nastavení a přihlašovací údaje. Ukázalo se, že místo, aby nechala umístění složky pro nastavení na Qt, které by ji umístilo do standardní cesty a v případě Flatpaku do sandboxu, natvrdo se snažila jej ukládat do /home. To by fungovalo, kdybych dal Datovce přístup do domovského adresáře uživatele, ale tím bych výrazně narušil sandbox, což jsem nechtěl. Nakonec to vyřešil jednoduchý patch, díky kterému Datovka ukládá nastavení do standardní cesty.

Dalším problémem bylo, že pokud jsem chtěl otevřít nějakou přílohu přímo (např. PDF v Evince), Datovka se soubor snažila uložit do /tmp. Opět někam, kde nemá přístup. Šlo by to vyřešit poskytnutím přístupu do celého hosta, ale znamenalo by to ještě větší narušení sandboxu než v předchozím případě. V tomto případě stačilo vytvořit spouštěcí skript, který nastavoval proměnnou prostředí TMPDIR=$XDG_CACHE_HOME, aby se soubor uložil do sandboxu. A pak byl předaný (jen) aplikaci, kterou uživatel vybere pro otevření.

A to bylo víceméně vše. Kromě přístupu k dconfu na hostovi (kvůli načtení tématu, nastavení písma atd.) nemá Datovka na úrovni souborového systému přístup k datům uživatele. Pokud do ní chcete nějaký soubor načíst (ať už je to příloha nebo třeba certifikát pro přihlášení), použije přes Qt portál a dostane přístup jenom k souboru, který uživatel vybere.

Datovka je docela typickým příkladem aplikace pro Linux. Byla psaná s tím, že má neomezený přístup do hosta, takže v sandboxu automaticky všechno nefunguje. Cesta nejmenšího odporu je jí prostě přístup do hosta povolit, ale často stačí jen pár drobných úprav na straně aplikace a funguje i v sandboxu bez problémů.

Pokud používáte prostředí založené na GTK+ a doinstalujete si QGnomePlatform rozšíření KDE runtimu, které překládá změny v nastavení GTK+ do Qt, bude se vám Datovka do prostředí integrovat i vzhledově.

Na Flathubu jsem musel projít standardním review, které je dost podobné tomu, kterým musíte projít, když chcete dostat balíček do distribuce. Např. Snap Store něco takového nedělá (sandboxované snapy jsou přijaté automaticky, nesandboxované projdou jenom rychlou bezpečnostní prohlídkou), což si myslím je škoda, protože se na to podívají odborníci, kterým prošly rukama už stovky manifestů, a zatím mi vždycky pomohli manifest výrazně vyladit (odstranit zbytečně bundlované závislosti, upravit tak, aby se to sestatovalo i na ostatních architekturách, odstranit práva, která aplikace nutně nepotřebuje atd.).

Na Flathubu je taky preferované, aby se o flatpaky starali přímo upstreamoví vývojáři, takže jsem je přes jeden svůj kontakt v CZ.NICu oslovil, jestli by Datovku ve Flathubu nechtěli převzít. Zájem nebyl. Navíc mě požádali, abych do popisu přidal, že flatpak není spravovaný jimi. S tím nemám problém. Myslím si, že když se o flatpak stará někdo jiný než upstreamový vývojář, mělo by to být uživateli deklarované.

CZ.NIC dělá v OBS oficiální balíčky pro 3 distribuce (Fedora, Debian, Ubuntu) a testují to ještě na Linux Mintu a Gentoo. Flatpak samozřejmě pokrývá výrazně víc a také na rozdíl od balíčků CZ.NICu podporuje taky architekturu ARM, proto si myslím, že má smysl ho pro Datovku udržovat. Datovka už neprochází nějakým překotným vývojem a Flatpak poskytuje na všech distribucích stejné prostředí, stačí tedy testovat jenom jednou, takže si nemyslím, že údržba flatpaku Datovky bude náročná, a není to nic, o co bych se nemohl starat sám.

Zkusím ještě, jestli upstream nebude mít zájem o patche, které jsme udělali, aby Datovka ve Flatpaku dobře běžela. Myslím, že mají smysl obecně. Navíc bych jim chtěl navrhnout, aby přešli u ID aplikace na schéma reverse-DNS, v tomto případě org.cznic.Datovka, které jsem musel použít, protože Flatpakem je vyžadováno, ale hodí se obecně pro unikátní identifikaci aplikace třeba pro uživatelská hodnocení napříč distribucemi.

Závěrem bych chtěl poděkovat Honzovi Grulichovi, který mi hodně pomohl hlavně s věcmi kolem Qt.

A ještě tedy profil Datovky na Flathubu 😉