This is a potentially long-term goal, but it's an important one that deserves to be tracked.
Flatpak is an important part of our stategic direction. It provides a better app update experience, opens the door to providing a wider range of apps, and is a requirement for Silverblue. A key milestone in our adoption of Flatpak will be to use it for our preinstalled apps.
There might be odd cases where an app can't be distributed as a Flatpak, due to its level of system integration, but otherwise, every preinstalled app should be a Flatpak.
My understanding is that the main blocker that needs to be resolved is getting support in anaconda for preinstalling Flatpaks.
The support is there at least for Silverblue. @jkonecny might tell us whether it can be used on Workstation as well or it will need to be written from scratch.
Hi everyone. Yes, there is already support for Fedora SilverBlue in Anaconda and it could be adopted to Fedora Workstation too. Right now, we are basically looking on a specific place on the boot.iso and installing everything from there to the target system with fixing the refs after that.
IMHO I see one problem we have to sort out. Fedora SilverBlue is using boot.iso (net install) but Fedora Workstation is Live DVD. That is not a complication for the flatpak algorithm but the main payload is rsync of the content of Live DVD to the target system "completely". So if on the Live media will be flatpak repository we would just copy that to the target system with the current logic. However, the above should be easy to fix by exclude in the rsync. We just have to keep that in our mind during implementation and testing.
My understanding is that the main blocker that needs to be resolved is getting support in anaconda for preinstalling Flatpaks
A few of the preinstalled flatpaks on Silverblue don't work properly due to limitations in xdg-desktop-portal. For example, printing is essentially broken for both eog and evince. Both use custom print dialog UI to format prints correctly, but the current design of the portal-based print flow doesn't allow any customization of the print dialog, let alone the arbitrary widgets used by some programs.
eog
evince
Custom print dialogs can never be supported. The apps just need to stop using them.
Well, the portals could in theory provide some customization. But certainly not arbitrary widgets.
We talked about this at yesterday's WG meeting. The general consensus was that we do want to ship preinstalled apps as Flatpaks, though @ngompa raised some concerns about outstanding integration bugs that it would be good to track.
Initial tasks:
@otaylor has kindly agreed to have a look at that.
Metadata Update from @aday: - Issue assigned to otaylor - Issue set to the milestone: Fedora 37 - Issue tagged with: pending-action
Please feel free to contact me if you need more info about the Anaconda part.
We discussed this issue during yesterday's working group meeting. @otaylor has some in-progress work that he's going to finish up and share. There will likely be other tasks to assign once that's done.
@otaylor has privately shared his work, so I think we can pass this work back to the working group. The following steps will need be shared around:
Metadata Update from @aday: - Assignee reset - Issue untagged with: pending-action - Issue tagged with: meeting
Metadata Update from @aday: - Issue assigned to aday
Another point to (possibly) keep track of is the list of apps that are dependent on evolution-data-server -used by core apps like Contacts & Calendar- since there is no sandboxing support in that API
Albeit Chromium isn't preinstalled, I think it would be great to switch it to the flatpak format because of the following reasons:
Are these reasons valid? Can I open a separated issue for this request?
Any Fedora Flatpak of Chromium would inherit the same problems from the RPM version. Meanwhile, any Flathub Flatpak would already be available -- and take precedence in GNOME Software -- once #300 is implemented. So I'm not sure we need to do anything. I suppose we could ask for the Chromium RPM package to be retired, but that doesn't seem too useful? Chromium is not part of Fedora Workstation beyond the fact that there is a Fedora RPM available to install, so it's probably better to discuss with the package maintainer than with us?_
Anyway, Workstation WG kinda discussed this ticket at the last meeting. Neal is opposed to preinstalled flatpaks, but I believe the rest of us want to do it. We have not yet approved the change, though.
As mentioned in #315 this can be only be done after there's a better QA process for Fedora Flatpaks, as a couple ones I've tested are slightly or completely broken compared to their Flathub counterparts:
Given the current single source of failure (@kalev) and infra issues with flatpaks, I think the soonest this can happen, practically is Fedora 38. But the change proposal can land anytime. I prefer to see flatpaks by default in Rawhide for a while to get as much lead testing time and any fallout as early as possible.
Clearly not going to happen for F37.
Metadata Update from @aday: - Issue set to the milestone: Fedora 38 (was: Fedora 37)
Action item: Neal to create a list of Flatpak technical concerns that have not yet been addressed
It looks like the WG has consensus that we want to replace all (or almost all) preinstalled apps with Fedora Flatpaks. We're still waiting for Neal to prepare a list of technical concerns, which the new Fedora Flatpak SIG will review.
My $0.02: some of these technical concerns may be missing portals, some may require applications to adapt their code to use portals, and some may just be bugs.
Metadata Update from @catanzaro: - Issue untagged with: meeting
This is a non-exhaustive list, but this is some of the biggest pain points I and others have with Flatpaks...
There's no way for users to understand what permissions Flatpaks have and how to override them when needed (either to open or close things) - note, this is a GNOME-specific problem, as KDE Plasma fixed this with Plasma 5.27
We currently display the app permissions in GNOME Settings -> Applications but those are read-only.
There are discussion in GNOME to allow for overriding permissions https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/653 https://discourse.gnome.org/t/gnome-application-settings-should-include-flatpak-permissions/12359
@aday considering this, and also given the results of the gnome-info-collect research showing high usage of Flatseal, do you think we should reconsider the option of allowing to override Flatpak permissions in GNOME Settings?
Thanks for the list, @ngompa . Could we try and stick to specific issues? There are some generalisations in your list - it's hard to know what they're referring to.
Storage access is broken (e.g. Steam game drives) and requires custom tweaking to access
What kind of storage access is this? Are there other examples other than Steam?
Basic use-cases for transparently handling user interactions are broken with no obvious way to fix it (drag and drop files from app to app)
Is this just drag and drop? You make it sound like there are other issues in this category, but what are they?
Visual style integration (themes, fonts, desktop settings) don't reliably work
Do you have any more specifics on these? Themes, fonts and desktop settings seem somewhat different from one another.
It's not that I'm against settings for app permissions - it's just that I want to make sure that those settings work, and don't break things. From what I've seen, Flatpak build permissions just aren't implemented with user modification in mind.
It would be good to have this conversation on the Flatpak side, though sadly the resourcing situation makes that difficult.
Thanks for the list, @ngompa . Could we try and stick to specific issues? There are some generalisations in your list - it's hard to know what they're referring to. Storage access is broken (e.g. Steam game drives) and requires custom tweaking to access What kind of storage access is this? Are there other examples other than Steam?
Steam was the most obvious issue, but I also had trouble doing things like sharing pictures from Element until I tweaked it with Flatseal to work, as I mention next.
Basic use-cases for transparently handling user interactions are broken with no obvious way to fix it (drag and drop files from app to app) Is this just drag and drop? You make it sound like there are other issues in this category, but what are they?
Drag-and-drop is the most visible breakage, but I also experienced apps like Slack, Element, and Telegram not having access to my pictures or documents until I overrode them with Flatseal.
Visual style integration (themes, fonts, desktop settings) don't reliably work Do you have any more specifics on these? Themes, fonts and desktop settings seem somewhat different from one another.
Font corruption is the biggest issue. Desktop scaling factor not being respected in some apps is the next one (that makes apps unusable on HiDPI screens). These issues showed up with the OBS Studio.
Next would be if I have a non-Adwaita/Breeze theme, it's not replicated into Flatpak apps (and yes I'm aware GNOME apps are hardcoded, I don't use GNOME apps through Flatpak, so I know that I'm not being blocked by libadwaita). I encountered this with Handbrake.
@aday considering this, and also given the results of the gnome-info-collect research showing high usage of Flatseal, do you think we should reconsider the option of allowing to override Flatpak permissions in GNOME Settings? It's not that I'm against settings for app permissions - it's just that I want to make sure that those settings work, and don't break things. From what I've seen, Flatpak build permissions just aren't implemented with user modification in mind.
I'm surprised that happened, to be honest. Android has been backing out of that mistake for almost five years now. iOS too. And my understanding is that Flatpak's permission and portal modeling is inspired by Android's system. That is the crux of what is so frustrating about Flatpak, it eliminates user control by default.
Thanks @ngompa . The next step is probably to transfer these issues to a pad or a wiki page, so we can track each one. I'd probably go for an etherpad myself, but if anyone has a different idea, please say.
Think of Flatseal as a workaround for broken flatpaks. You shouldn't need it and we shouldn't build user interfaces around it. The fact that installation of flatseal is so high is very concerning and indicates general failure in the flatpak ecosystem.
I've made a start on hunting down each issue here - https://etherpad.opensuse.org/p/flatpak-ux-issues . Help would be welcome!
See, here's the problem with this thinking: you assume that the developer knows better than the user about what they may or may not want an app to do. This was a mistake that Android and iOS had with their sandboxes for years. Ultimately, they had to begin the painful process of fixing that after so many user complaints over the years. Windows and macOS both put sandbox knobs in control of the user. The fact that we didn't is our failure.
See, here's the problem with this thinking
Please let's avoid personal accusations. This position could be easily expressed as: "it's better to provide user control over sandbox permissions, because X and Y."
Underpinning the problems with Flatpaks is an incongruity of mindset and philosophy. Without resolving that, we're going to keep having problems like this. I'm not specifically attacking @catanzaro, I'm specifically pointing out that the statement (and thinking behind it) is flawed. Without dealing with that problem, we can't make Flatpaks better for the user.
@ngompa when you write "you assume that the developer knows better than the user about what they may or may not want an app to do", that's a personal comment which sounds very hostile.
For the sake of having a healthy discussion, it would be better to stick to the issues and leave concerns about "mindset" out of it.
If we can't fix the problem with how Flatpaks are approached by Workstation and upstream (which affects fixing issues, prioritization of UX development, etc.), then I don't want Flatpaks preinstalled on Workstation Edition ever.
It's that important to me that we don't cede control from the user to the developer. Fedora Flatpaks offer a good compromise by ensuring every Flatpak can be built from source from a process that is publicly auditable. But it doesn't change the fact that Flatpak experiences in GNOME are suboptimal compared to how sandboxed apps work in Windows, macOS, iOS, and Android. And it's suboptimal because there's an assumption that users shouldn't be able to manage permissions for their applications.
I have far too much experience on the Windows/Mac/Android side of things to know how badly it goes when users have no say in what apps are allowed to access.
And I will point out that I made the same arguments to the KDE folks and that's why KDE Plasma has a better Flatpak experience than GNOME does, starting with Plasma 5.27.
And it also explains why Flatseal is installed by so many people on GNOME desktops you surveyed. It's a huge gap that exists only because there's an attitude that it "doesn't belong". I'm saying that's completely wrong and the data and competitors all agree with me on this.
I'm not feeling any hostility from ngompa here. :P
I'm skeptical about giving users control of static permissions, but maybe it's not ridiculous. But for this to be successful, we'll need to discuss it upstream and get buy-in from the entire Flatpak ecosystem. Even though only gnome-control-center would need to change, gnome-control-center is not likely going to want to change unless the Flatpak community says "yes this is actually a good idea." Very importantly, we need to make sure that giving users access to static permissions does not reduce developer incentive to use portals properly.
(And that said, users should really not be expected to change the permissions, even if they can.)
This part, I agree with. They shouldn't need to. But it shouldn't be hard to do so if they want to.
This is a very heated discussion.
Lets discuss this in person, rather than letting this spin out of control further
Here's a font corruption bug.
I already discussed in September 2018, on the fedora-desktop list that the way we created Fedora Flatpaks then, and now, adds work for packagers and involved upstream maintainers ("Call for participation: Fedora Flatpaks"). Discounting the problem of the additional workload for maintainers, there are still a number of problems with the infrastructure and the changes being made to build Flatpaks from the existing RPMs.
I'll use GNOME Videos/totem as an example, because it does a number of things that are currently not possible using the Fedora Flatpak infrastructure. Please refer to the upstream Flatpak manifest for the original implementation: https://github.com/flathub/org.gnome.Totem
1) embedded daemons The upstream totem embeds dleyna-server and tracker to not require the host to provide those. It also sandboxes them for free. This requires the manifest to pass the app-id-prefix to those daemon's spec files to use.
The other option would be to simply remove those dependencies and hope that the user would have those services installed. Maybe that's the case for Tracker if they use GNOME, but what else is going to drag dleyna-server in? And who will be there to answer the questions about DLNA browsing not working on all the Fedora support channels even the ones we don't know about.
In short, we don't want to ship a bag of bits, and we need to be sure that those daemons are present and functional to offer a product.
2) Debuggability
Manifests in the git repositories just mention a Fedora release branch for where they need to pick up the spec files to churn through to build the Flatpak. But there's no equivalent to flatpak-builder's /app/manifest.json file. Not even talking about reproducible builds, we have no way of knowing which version of a library, package or spec file was used to create the build we're running.
There are also no .Sources or .Debug package extensions that would allow for easier and/or better debugging.
3) Default permissions
I noticed that some packages had "session-bus" in their default permissions: https://src.fedoraproject.org/flatpaks/foobillard/blob/stable/f/container.yaml
Is there any kind of gating or checks made for the default permissions in the Flatpaks? If and when we start shipping Flatpaks to end-users rather than early adopters, we need to have a clear review workflow to stop this kind of permission from slipping into the software we offer, and for it to be applied retroactively to all the existing software.
4) Codecs
Finally, one of the major problems. There is currently no mechanism for automatic codecs installation using the GStreamer missing plugins infrastructure and Fedora will never be able to ship all the codecs that the Flathub version of totem can.
We also have the problem that tracker, which totem relies on for finding local videos, might be similarly incapable of handling certain videos and that whether it's the host tracker, or the embedded tracker.
Flatpak has a mechanism for autodownloading extensions when they become available. I would recommend that this is used for extending totem instead of piggy-backing on the GStreamer missing plugins system, and that extensions from other sources are discussed with community stakeholders before those apps are deployed.
Having limited H264 support, and only that, might be good enough for a web browser that can negotiate different codecs with the server, but it's completely useless to play back the file that the user already has on their disk.
In short, the Fedora Flatpak infrastructure needs to: - pass the app-id of the application or runtime that's being built to customise daemons to use that prefix (eg. org.gnome.Totem.Tracker) - add support for creating .Sources and .Debug extensions - add gating/blocklist mechanism for certain egregious permissions (like bus access) - write packaging guidelines, or extend the existing docs to refer to best practices from upstream Flatpak - add support for creating extensions, including auto-downloadable ones - discuss with the community about providing a codec extension with more coverage
Thanks Bastien! This is a helpful to-do list.
I'll just add that the plan is to not provide .Sources or .Debug extensions and instead mandate use of debuginfod for debugging flatpaks. (We need to make sure that debuginfod can indeed actually handle our flatpaks.)
Thanks Bastien! This is a helpful to-do list. I'll just add that the plan is to not provide .Sources or .Debug extensions and instead mandate use of debuginfod for debugging flatpaks. (We need to make sure that debuginfod can indeed actually handle our flatpaks.)
You'll definitely need a way to figure out how to match package sources and versions to the crashing and/or running code. If it's not a debugging requirement, it will be a license compliance one in short order.
Right now there's no infrastructure for either license compliance or debugging.
I'm skeptical about giving users control of static permissions, but maybe it's not ridiculous. But for this to be successful, we'll need to discuss it upstream and get buy-in from the entire Flatpak ecosystem. Even though only gnome-control-center would need to change, gnome-control-center is not likely going to want to change unless the Flatpak community says "yes this is actually a good idea."
There is no reason why such permissions are inherently static. On Android or iOS for example, users can grant an application access to their photos storage and revoke it whenever they please. It is up to the application to handle such permission changes.
However, to implement dynamic permissions you need an API for applications to request permissions. Here is Android's. Where would such an API belong in the context of Flatpak?
xdg-desktop-portal
Metadata Update from @aday: - Issue set to the milestone: None (was: Fedora 38)
Hm, I thought @otaylor was working on this, but I see the issue is assigned to @aday. Could one of you provide a status update please?
I'm not sure how much I can do about this issue and I'm not sure what needs to be done. It might be good for us to discuss it again in a meeting.
Metadata Update from @aday: - Assignee reset - Issue tagged with: meeting-request
Metadata Update from @catanzaro: - Issue untagged with: meeting-request - Issue tagged with: meeting
We discussed this at length today. @otaylor will provide a status update on the various work items and remaining problems and questions.
While we're not there yet, there has definitely been some motion here that gets us closer to being able to implement this.
With the F39 FlatpaksWithoutModules change,we now have a much more solid infrastructure for building Flatpaks that is more friendly for contributors and that we can use on all architectures. (We do not currently build for s390x, but we could.)
The main gap on the infrastructure side at this point is automatic rebuilds, both automatically rebuilding the RPMs and rebuilding Flatpaks out of those RPMs. This is my top Flatpak infrastructure priority for the next cycle, though since we don't have an actual plan for rebuilding the Flatpaks yet, I'm not sure if we'll have some sort of solution for F40 or it might take another cycle beyond that. (Hopefully F40!)
I've been recently working on designing a Flatpak feature to give the core of Flatpak an idea of what should be preinstalled. https://github.com/flatpak/flatpak/issues/5579 - this has a couple of targets - first, it's meant to provide a way for Flatpak preinstallation can slot into an installer, in a way that can work across packaged-based installation and image-based installation, replacing the somewhat hackish way we install Flatpak for Silverblue. Second, it provides a way to change the set of preinstalled Flatpaks across operating system updates.
Other gaps are:
At the Fedora Workstation Working Group meeting today, we discussed the issue that Fedora Flatpaks are single stream - if we switch Clocks to running as a Flatpak, then as soon as F41 (GNOME 47) is released, then F40 users will get the update to GNOME 47 Clocks - working group members generally didn't consider this to be a big deal, though there were a couple of caveats:
A final thing we need to improve is the pre-release period. Right now, we have once we create a Bodhi update for a F39 Flatpak, we can't update the same Flatpak for F38, and we have to mark F39 Flatpaks stable before we build the final release media, which means that they get released before F39 GA
We'd really like to be able to use the normal Bodhi multi-release flow, and have that do the "right thing" - F39 media is built with F39 Flatpaks. Installs from F39 media see F39 Flatpaks. You can opt into that F39 Flatpak stream for testing. At F39 release, F39 Flatpaks join the main stream. We'll try to come up with some solution for this for F40.
I would like for us to preload Flatseal on Workstation still.
I have a feeling that Flatseal exposes may technical details. User can easily break the app (make it not launching) or break the sandbox with it. It's very nice tool for power users but it should not be required in default user experience. If it's required by default, that's just the issue with Flatpak itself or missing APIs, or with the particular app.
That's kind of the point. It needs to be exposed somewhere otherwise you've shifted the power balance completely away from the user with Flatpaks. KDE, Windows, Android, and iOS/iPadOS/macOS all provide this because they've learned over the years that trusting the developer exclusively is not tenable.
It needs to be exposed somewhere
Isn't that still possible though with the flatpak command itself?
for example: flatpak override --filesystem=home org.mozilla.Firefox
flatpak override --filesystem=home org.mozilla.Firefox
Like you said, it still allows anyone to override permissions when the developers haven't taken care of the clean behavior in the sandbox.
My personal concern in exposing a default UI for this type of override is that working around those issues will become "expected behavior" and long term will become part of the "Flatpak experience" to users, rather than expecting those bugs to be solved by the developers.
KDE, Windows, Android, and iOS/iPadOS/macOS all provide this because they've learned over the years that trusting the developer exclusively is not tenable.
The difference between FlatSeal and for example the permissions in those other OSes is that FlatSeal is a direct 1:1 mapping on the overridable parameters of the flatpak sandbox. Windows 10, Android and iOS do not expose anything about giving access to sockets or D-Bus services, which environment variables should be set or whether you want to expose "GPU acceleration". Instead, they usually expose whether you want to expose some privacy-conscious properties such as exposing the camera, microphone etc (e.g. https://support.google.com/android/answer/9431959?hl=en#zippy=%2Ctypes-of-permissions). So not too different from what we do in GNOME Settings in the "Privacy" section.
It needs to be exposed somewhere Isn't that still possible though with the flatpak command itself? for example: flatpak override --filesystem=home org.mozilla.Firefox Like you said, it still allows anyone to override permissions when the developers haven't taken care of the clean behavior in the sandbox.
The Workstation WG has generally considered command-line interfaces as non-solutions. I personally do not like using the CLI as a cop-out answer for anything, especially for a solution that is explicitly and exclusively used for graphical applications.
It already is. We have long since passed that point. And as Flathub moves to "direct upload" Flatpaks, this will become more of a problem over time.
KDE, Windows, Android, and iOS/iPadOS/macOS all provide this because they've learned over the years that trusting the developer exclusively is not tenable. The difference between FlatSeal and for example the permissions in those other OSes is that FlatSeal is a direct 1:1 mapping on the overridable parameters of the flatpak sandbox. Windows 10, Android and iOS do not expose anything about giving access to sockets or D-Bus services, which environment variables should be set or whether you want to expose "GPU acceleration". Instead, they usually expose whether you want to expose some privacy-conscious properties such as exposing the camera, microphone etc (e.g. https://support.google.com/android/answer/9431959?hl=en#zippy=%2Ctypes-of-permissions). So not too different from what we do in GNOME Settings in the "Privacy" section.
The difference is that users cannot grant or take away static permissions in GNOME Settings. I can do this in KDE's Flatpak settings management interface. We have actual data showing that Flatseal is installed and used by a majority of the GNOME user base that we've got data from.
As long as GNOME continues to hesitate to integrate an interface into GNOME Settings, I will continue to push for Flatseal to be preloaded. All we're doing by not preloading it is making things harder for people.
My $0.02: Settings should gain a flatseal-like UI that allows removing static permissions declared by applications, but not adding new permissions. If an app requires new permissions, that's a bug to be fixed by application developers. Using flatseal to add extra permissions is an ugly workaround.
If Settings does not have any UI for permission control, then users will just use Flatseal instead. We have no influence over user behavior if we're not playing the game at all.
Metadata Update from @ngompa: - Issue tagged with: default-apps, experience
Well, here's an example of routine need to use Flatseal to make a Flatpak useful.
@ngompa I think that instead there should be extended APIs so Flatseal won't be needed in a range of standard user experience.
Login to comment on this ticket.