A Flatpak jövője: hátrahagyhatja a nem systemd disztribúciókat

enlightened Ez az oldal a közösségért készül. heart Kövess minket máshol is:  Linux Mint Magyar Közösség a Mastodon-on  Telegram csatorna – csak hírek  Beszélgessünk a Telegram – Linux csevegő csoport  Hírek olvasása RSS segítségével  Linux Mint Hivatalos Magyar Közösség a Facebook-on      Linux Mint Baráti Kör a Facebook-on
wink Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát Ko-fi vagy Paypal segítségével. laugh

kami911 képe

A Flatpak fejlesztői jelentős architekturális változtatásokat tárgyalnak, amelyek középpontjába állíthatják a systemd-et a Flatpak következő generációs sandboxing modelljében. Ez felveti a kérdést a projekt hosszú távú kompatibilitásáról a nem systemd Linux disztribúciókkal.

Tavaly novemberben Sebastian Wick, a Flatpak karbantartója, közzétett egy projektfrissítést. Megjegyezte, hogy a fejlesztés lelassult, miután a karbantartók visszavonultak, de azóta nőtt a tevékenység, újra fókuszálva a függőben lévő egyesítési kérelmekre, az OCI támogatásra, az előtelepített alkalmazásokra és az engedélykezelésre.

A fő aggodalom a Flatpak Next hosszú távú irányvonala, amely egy korai tervezési kezdeményezés a jövőbeli architektúrára, ami egy jelentős 2.0-ás stílusú újratervezéshez vezethet. Ezt Wick és Adrian Vovk nyilvánosan megvitatta néhány nappal ezelőtt a Linux App Summit 2026-on.

Ennek a jövőbeli munkának a kulcsfontosságú eleme a systemd-appd, egy javasolt systemd komponens, amely az alkalmazás példányok futásáról nyújt információt. Wick kijelenti, hogy a systemd-appd célja a Flatpak példányok hitelesítésének támogatása, a beágyazott sandboxing lehetővé tétele, a PipeWire integrációjának javítása, és végül a Flatpak jelenlegi D-Bus proxy modelljének helyettesítése.

Ez jelentős, mert a Flatpak jelenlegi architektúrájának számos korlátja van. Korábbi tervezési dokumentumok megjegyzik, hogy a Flatpak már kéri a systemd-et, hogy rendelje az alkalmazás példányokat a megfelelő cgroups-hoz, bár ez a lépés jelenleg következmények nélkül meghiúsulhat. A jövőbeli tervek megkövetelhetik, hogy minden alkalmazás példányhoz cgroup tartozzon, amelyet a systemd vagy közvetlenül kezelnek, hogy támogassák az alkalmazás azonosítást és a metaadatok nyomon követését.

A technikai motiváció világos: a Flatpak robusztusabb módszereket igényel a futó alkalmazások azonosítására, az engedélyek kezelésére, a beágyazott sandboxok támogatására, és az asztali szolgáltatásokkal, például portálokkal és PipeWire-rel való integrációra. Ezek a fejlesztések különösen fontosak a komplex alkalmazások, például böngészők és belső sandboxinggal rendelkező alkalmazások esetében.

Ugyanakkor ez a javasolt irányvonal érzékeny kérdést vet fel a Linux ökoszisztémában: vajon egy disztribúciók közötti alkalmazásplatformnak kell-e függenie a systemd-től. Ahogy sejthető, ez a probléma elsősorban a nem systemd disztribúciókat érinti, mint például az Alpine, Void, Devuan és mások, amelyek szándékosan elkerülik a systemd-et.

Jelenleg a Flatpak a szélesebb Linux asztali környezettel van összefüggésben, nem pedig egyetlen disztribúciós családdal. Ha a jövőbeli Flatpak kiadások megkövetelik a systemd-appd-t kompatibilis alternatíva nélkül, ezeknek a disztribúcióknak lehetséges, hogy lefelé irányuló javítócsomagokat kell alkalmazniuk, fenntartaniuk egy helyettesítő réteget, vagy lemondaniuk a teljes Flatpak támogatásról.

Végül fontos megjegyezni, hogy a Flatpak jelenleg nem igényli a systemd-appd-t a stabil kiadásokban, és a systemd-appd még nem egy befejezett vagy széles körben telepített komponens.

A jelenlegi diskurzus a jövőbeli architektúrára vonatkozik, különösen a Flatpak Next-re, és arra a munkára, amelyet a fejlesztők szükségesnek tartanak a régóta fennálló tervezési korlátok kezelésére. Azonban a következő generációs sandboxing olyan infrastruktúrára épül, amely jelentősen megnehezítheti a systemd elkerülését.