All the current Flatpak runtimes in wide use are based on the 1.6 Freedesktop runtime. This is a two-layered beast where the lower layer is built using Yocto and the upper layer is built using flatpak-builder.
Yocto let us get a basic system bootstrapped, but it is not really a great match for the needs of a Flatpak runtime. We’ve long wanted a base that targeted sandboxed builds which is closer to upstream and without the embedded cross-compiled legacy of Yocto. This is part of the reason why Tristan started working on BuildStream, and why the 1.8 Freedesktop runtime was created from scratch, using it.
After a herculean effort from the people at Codethink (who sponsor this effort) we now have a working Yocto-free version of the Platform and Sdk. You can download the unstable version from here and start playing with it. It is not yet frozen or API/ABI stable, but its getting there.
The next step in this effort is to test it as widely as possible to catch any issues before the release is frozen. In order to do this I rebased the Gnome nightly runtime builds on top of the new Freedesktop version this week. This is a good match for a test release, because it has no real ABI requirements (being rebuilt with the apps daily), yet gets a fair amount of testing.
WARNING: During the initial phase it is likely that there will be problems. Please test your apps extra carefully and report all the issues you find.
In the future, the goal is to also convert the Gnome runtimes to BuildStream. Work on this has started, but for now we want to focus on getting the base runtime stable.
4 thoughts on “Introducing the 1.8 freedesktop runtime in the gnome nightly builds”
Great work guys, but:
“Yocto let us get a basic system bootstrapped, but it is not really a great match for the needs of a Flatpak runtime.”
What’s the real/big gain with this move? Are flatpak files going to be smaller, faster or what?
Isaque: The gain is that maintaining the runtime is easier, which in the end will be better for end users too.
Multiarch is also a big benefit – it becomes much easier/possible to do things like having 32-bit libraries added to a 64-bit runtime without horrible path hacks, or even adding non-emulated cross-compilers as an extension in a target arch runtime.
Comments are closed.