So, I have recently set up an old laptop of mine with GNOME OS to test it a bit more.
One thing I noticed is that a lot of applications come pre-installed in the system image. For example, you can find both Evince and Papers in the main system image, and Builder in the devel system extension.
Now, a few of these applications are system applications (like Files or Settings), where the inclusion in the image is reasonable. But for others, like Papers, Loupe and others it would make more sense to have them as Flatpaks, right? As this would permit users to uninstall unwanted apps, use sandboxing, etc.
I would assume that the main reason for the inclusion is that the applications are, like the system, nightly builds from the current development branches. It is GNOME OS Nightly after all. However, the Flatpaks from the GNOME Nightly repository should be on the same development state, right?
The other reason I can think of is that there isn’t currently a mechanism for Flatpak apps on installation and reset. As of now, the image does configure Flatpak remotes, but no Flatpak apps. And it wouldn’t be ideal to have a fresh install or reset system with no apps…
What I would like to know is: Considering there are plans to turn GNOME OS into an general-purpose system, what is the idea for applications? Is the plan to keep the currently pre-installed apps as part of the system, or would the eventual plan be to distribute them with Flatpak?
I would like to add that especially with the devel extension there are quite a few things I would consider better being in a Flatpak.
If I install the devel extensions because I need git and meson, I don’t expect things like the GTK or librest demo to be unremovable parts of the package.
If I understand it right, a fresh GNOME OS system is deployed without the data partition, as this can be created on first run.
But this also leaves only immutable partitions where apps can be pre-delivered with. The only things I can think of are downloading Flatpaks on initial setup (which is bad for offline setup) or having a sideload repo compressed in the image (which is silly and waste space).
So, I guess the apps will have to stay pre-installed and unremovable then. Or is there a concept to solve this?
You are not the only one who is bothered by it. I have heard some approaches. I think Adrian had some ideas. Maybe when he sees this post, he can remind us what it was.
Note that in the end there is no perfect solution. At least not that I am aware of.
Being able to easily disable an applications (like Hidden in the desktop files) from Software would be nice.
And maybe make flatpak being able to run /usr applications in confinement would also be something interesting.
What ever approach we have, we have to think: will it work with factory reset?
Yeah we’re definitely going to start shipping things as Flatpak at some point. I think quite literally all of the GNOME OS folks are on the same page about that.
As for how… that’s complicated. Lots of factors to consider. Most have been pointed out here. It also depends on what you’re trying to achieve by Flatpaking the apps. Here’s a list of things we might achieve, in no particular order of importance:
Sandboxing
Uninstalling built-in apps, to remove an unnecessary icon from the system (app grid, “open in” dialogs, etc)
Uninstalling built-in apps, to free up storage space
Updating built-in apps beyond the version that ships with the core OS
Ability to use patented video codecs, via an extension downloaded at runtime
Next some requirements. The solution must:
Behave correctly during a factory reset. That means that all the default GNOME apps should be re-installed during the factory reset
Work offline
Work quickly. We don’t want to ever be in a situation where a user sits and waits 30 minutes for their apps to slowly install during first boot, or during a system update
Minimize the amount of space used on the user’s disk
Minimize the amount of data sent over the network to install updates
Maximize the list of benefits above
Not interfere with our build system
Not interfere with GNOME OS’s role as GNOME’s automated QA platform
I’ve spent months thinking about this. My current favorite solution is to install the apps into /usr but still run them via a Flatpak sandbox. Here’s how that could work:
We teach Flatpak to treat /usr as a special runtime, that we’d call org.flatpak.HostSystem
We install the apps into /usr, just like we currently do. We’d remove the .desktop file from /usr/share though, so that the unsandboxed version of the app doesn’t appear in the UI.
Maybe it’s worth moving the primary executable out of $PATH as well. This way, the user won’t accidentally run the app unsandboxed from the command line, when they could run it sandboxed. Maybe we’d just move these executables from /usr/bin → /usr/app, or something like that?
At this point, it’s possible to run these system-installed apps with a Flatpak sandbox! Just do: flatpak run --command=/usr/bin/app-name --device=dri --socket=wayland ... org.flatpak.HostSystem
We’d teach Flatpak about a new type of app we’d call a “stub”. These apps would just be a way to assign an app ID to that command-line invocation above. So you could do flatpak run org.gnome.Calculator from the CLI, and it would translate that into flatpak run --command=/usr/bin/gnome-calculator --socket=wayland --socket=fallback-x11 --device=dri --share=network --share=ipc org.flatpak.HostSystem
We preinstall the stub apps, such that they’re just available for any user system wide. This would probably need some special support in Flatpak.
We teach Flatpak and/or GNOME Software that it can “uninstall”/disable stub apps by just creating a .desktop file with Hidden=true in some per-user directory.
Let’s see how this solution fares with our goals and requirements.
Sandboxing
Uninstalling to hide the icon
Minimize space use on disk
These apps live entirely on the immutable partition. The immutable partition has a fixed size, and has a relatively large (compared to the built-in apps) amount of unused slack space at the end for future OS expansion
No matter how big the set of built-in apps gets, it will never eat into the user’s available free space. It’ll only eat into the slack space in the immutable partition. This, this solution is “free” in terms of space on disk
Uninstalling to save space
This just doesn’t make sense given the above. Even if we physically deleted the app’s data from disk, that would only increase the amount of unusable slack space inside of the immutable partition. It wouldn’t give more free space to the user data partition.
Updating built-in apps past the version that shipped with the OS
I don’t think this is a huge deal in practice. Realistically, GNOME OS will naturally get updates (i.e. security updates, and GNOME point releases) at roughly the same rate than the built-in apps.
Plus, it’s still possible to do manually. We can make the stub apps use the same app IDs as Flathub. Then the user could simply run flatpak install flathub $appid , and this would override the stub version with the Flathub version. The Flathub version then gets updates at its own pace.
Ability to use patented codecs
For GNOME OS, a given version of org.flatpak.HostSystem will be nearly identical to the same version of org.gnome.Platform. We’d just configure org.flatpak.HostSystem to use all of the same extension points. This means that Flatpak will automatically use extensions like the patented video codec package whenever available
Correct behavior during factory reset
The stub apps are always installed system-wide, so they always work. They are “uninstalled”/disabled by simply hiding the .desktop entry. So, factory reset, or even just creating a fresh user account, would “reinstall” these apps (there would be nothing to suppress the .desktop entry)
Works offline
Works quickly
Apps are completely installed and functional from the get-go. Can’t get faster than that
Minimize data sent over network
We ship updates to built-in apps just once. Some other solutions don’t.
Not interfere with build system
Basically nothing changes about the way we install apps. We keep installing them into /usr
Not interfere with ability to do QA testing
The apps are still completely runnable unsandboxed! So we can QA the apps in these circumstances. We’d just need to run the executable from /usr directly, without first going through flatpak run
We could then retest the exact same apps with a Flatpak sandbox, using the exact same tests. So actually this improves our flexibility. We could get better QA coverage this way.
The nightly GNOME OS images automatically contain the nightly versions of all the GNOME default apps. So we know for a fact that we really are testing the latest commits of the entire platform, top to bottom. Solutions that rely on the GNOME Nightly Flatpak repo risk getting the OS and the Flatpak repo out of sync, which would make the QA tests less effective.
So, overall this seems like the ideal solution. This is the best I could come up with so far, and I think it’s not too unreasonable to implement either.
