#151 Flatpak preferred over native (rpm) software in GNOME Software
Closed: Won't fix 3 years ago by catanzaro. Opened 3 years ago by mcrha.

This is kind of question, but also a rant. The GNOME Software (as noticed in Fedora 32, though maybe even earlier) prefers Flatpak (whichever source it comes from it seems) software over rpm software. While it can work fine for standalone applications (say Recipes), it's definitely not good for anything more complex, which needs to talk to the outer world and to the parts of the system.

I noticed it with the Evolution, after I (not really accidentally) made a Fedora Flatpak update for it [1]. This Flatpak version (the same as the one provided by Flathub.org) is very special, it runs in its own sandbox completely. It doesn't share the data with other applications, neither with GNOME Shell, and the way Flatpak is designed it adds a lot of limitations to the users. The current behaviour just breaks user experience.

Maybe it makes sense to install Flatpak version on Silverblue [2], but with Fedora Workstation, where the same (and currently also the better/higher version) is available as an rpm, the rpm version should be used. From my point of view.

Questions:
a) does Fedora Workstation need to default to Flatpak applications?
b) is there a way to disable Flatpak precedence per application? Should there be?

I do not want to give an impression that Flatpak is useless, it has its usages and it's good for older systems, where it would be very problematic to get to the latest packages due to dependencies, but it has also its limitations. It definitely doesn't make sense to install Flatpak version on a system where all the dependencies are native, easily available. Why to install 2GB or more (as the Platform bits for the Flatpak) just to duplicate what is already installed? Note that not everyone has quick internet connection and not everyone has plenty of disk space (I fight with the disk space all the time, if you wonder). Thus downloading the dependencies twice is just waste of time and resources. For me. Others might have different opinion.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2020-3436d27c33
[2] https://gitlab.gnome.org/GNOME/gnome-software/-/issues/655


It definitely doesn't make sense to install Flatpak version on a system where all the dependencies are native, easily available. Why to install 2GB or more (as the Platform bits for the Flatpak) just to duplicate what is already installed?

The benefit provided by the flatpak sandbox outweighs all other considerations IMO.

The benefit provided by the flatpak sandbox outweighs all other considerations IMO.

For those you quoted, yes (kind of personal opinion related, but I can agree with that). But when it comes to user experience, then the Flatpak is far from ideal. I guess you mean the Flatpak is more secure, but, well, it's "security by obscurity" (which is term I heard from a security folk years ago), especially if it breaks user experience the way it does break it.

My main concern is: when the system can use native application, which is well integrated with the whole desktop/system and all the other applications can use its data (which is not true with the Flatpak version of Evolution), then it should prefer the native application. Otherwise you break the user experience heavily. There are only-flatpak related bugs about things users use daily, but they cannot use them now, due to the flatpak version being installed.

Anyway, say I want to avoid this breakage in the future. It will mean that I won't build Fedora Flatpak version of Evolution again, but also that I should remove the now obsolete (obsolete by newer upstream release) Fedora Flatpak update I filled recently. Am I right? How do I do that? I didn't find a way to delete the update in the Bodhi web interface. That update is in the 'stable' state now.

And, similarly importantly, I cannot influence whether users have enabled Flathub.org repository (or any other?). Does that make any difference? Does the Flathub.org repository compete with Fedora Flatpak and with Fedora RPMS? Do you see how confusing the things can be? For the user, I mean.

My main concern is: when the system can use native application, which is well integrated with the whole desktop/system and all the other applications can use its data (which is not true with the Flatpak version of Evolution), then it should prefer the native application. Otherwise you break the user experience heavily. There are only-flatpak related bugs about things users use daily, but they cannot use them now, due to the flatpak version being installed.

Would you mind sharing links to these bugs? I am particularly interested in closing the integration gap between Flatpak'ed applications and native, so I might be able to help with those.

And, similarly importantly, I cannot influence whether users have enabled Flathub.org repository (or any other?). Does that make any difference? Does the Flathub.org repository compete with Fedora Flatpak and with Fedora RPMS? Do you see how confusing the things can be? For the user, I mean.

A non-experienced user should rely on the default Source option set by GNOME Software. An experienced one can use the Source popover to decide from where they want their application from. Which one is the default is indeed up for discussion.

I checked how this works and it seems the trick is to install through GNOME Software, not to update through it. As the Evolution is not part of the Live DVD (it seems), the users whom install with GNOME Software will received the Fedora Flatpak format (unless they notice the difference at the right top). When I do not have enabled the Fedora Flatpak repository in the GNOME Software the Flathub.org version is offered instead. (From which I suppose any Flatpak repository, even totally custom 3rd party repos, can win over the RPM.)

I know this can be natural to others, but it's not for me, thus I decided to mention it here.

Would you mind sharing links to these bugs?

Not everything had been filled as a bug, some had been rants by the users on the evolution-list and such. One common is about printing (that's https://bugs.webkit.org/show_bug.cgi?id=192748 ), another is about GAppInfo (evolution offers "Open with ...." for attachments, but as it runs in a sandbox the list of the applications is basically empty, which the users do not like). A very recent bug is about drag&drop of the files, which can be used to add attachments (honestly, I do not know what to do with that bug - https://gitlab.gnome.org/GNOME/evolution/-/issues/956 ). You can check what workarounds had been needed for the flatpak to make it even work ( https://gitlab.gnome.org/GNOME/evolution/-/issues?scope=all&utf8=%E2%9C%93&state=opened&search=flatpak ) and, of course, check the list of (not only opened) bugs against the Flathub.org version ( https://github.com/flathub/org.gnome.Evolution/issues/ ). And one Fedora Flatpak related: basically no localization, thus the interface runs in an English locale, despite the user chose to use their native language/locale (this is not the case for Flathub.org version, if the .Locale subpackages are installed for the project and the Platform).

One other thing is the cooperation with the rest of the desktop. Evolution is not only Evolution, it's just a client of the evolution-data-server. To get all the fixes, aka really all the new code, one needs to run also the evolution-data-server services in the sandbox, which Evolution does. The outcome (and the price) is that it isolated the downloaded data from the rest of the system, thus it cannot be used by other applications, either native or Flatpak-ed. The other Flatpak applications (say GNOME Calendar, GNOME To Do, GNOME Contacts...), which also use the evolution-data-server (eds), build their code against version X (possibly the latest), but then rely on the host system eds services, which means they do not use all the fixes (those on the backend side). I even changed the D-Bus APIs a year ago, which made their life harder. I know, this is by design of the Flatpak, though I hope you see that its limitations are not always negligible.

A non-experienced user should rely on the default Source option set by GNOME Software. An experienced one can use the Source popover to decide from where they want their application from.

In an ideal world, this should cover both users and it should give them the best available user experience by default. What the best user experience means can vary by application and the system. In case of Recipes, ehm, whichever is picked. In case of Evolution - the RPM version (where the system matches dependencies) should be preferred (aka installing Fedora Flatpak on Fedora 30, where the build is done against f32 runtime/platform is a different story than installing the same Fedora Flatpak version on a Fedora 32 Workstation; there apply different rules with the Silverblue).

@mcrha thanks for the list. I am going to go through them and see what I can help with.

In an ideal world, this should cover both users and it should give them the best available user experience by default. What the best user experience means can vary by application and the system. In case of Recipes, ehm, whichever is picked. In case of Evolution - the RPM version (where the system matches dependencies) should be preferred (aka installing Fedora Flatpak on Fedora 30, where the build is done against f32 runtime/platform is a different story than installing the same Fedora Flatpak version on a Fedora 32 Workstation; there apply different rules with the Silverblue).

I see. I think it would be reasonable for us to agree on an API for letting apps assert their preferred packaging method.

Our Flatpak story has been also about giving app distribution control to developers, and from my personal experience this has highly increased the quality of the apps I work on. But indeed there are exceptions, like Evolution, where Flatpak introduces some caveats. We should account for it (at least until we achieve feature parity).

The Fedora flatpak repo is not (and should not be) enabled by default in Workstation; that hasn't been approved (yet). I think the flatpak format is always preferred over RPM packages when both are available, but by default only RPMs are available, you have to opt-in and enable the repo manually in order to get either Fedora flatpaks or Flathub. Right?

Most of the issues you mentioned fall into two categories:

  • flatpak portal and portal usage bugs, e.g. printing doesn't work in WebKit, drag-and-drop doesn't work in WebKit, etc. These, we should consider a TODO list for platform improvements.
  • Application design bugs, e.g. Open With is just not possible under flatpak and Evolution should not be offering that. evolution-data-server being a system service with unstable API, it's difficult for apps to use it, but unstable API is a choice you make, it doesn't have to be that way. These are kinda on the application developer. ;)

The Fedora flatpak repo is not (and should not be) enabled by default in Workstation; that hasn't been approved (yet).

That's incorrect. The fedora flatpak repo has been enabled by default for the last two Fedora releases at least, maybe even more. And it doesn't need Workstation WG approval as it's not a third party repo.

The fedora flatpak repo has been enabled by default...

Right, I just booted Fedora-Workstation-Live-x86_64-32-1.6.iso and this is what GNOME Software shows. Note of the "Enable 3rd-party repositories" question at the background window (though it doesn't bring in Flathub.org, thus it's eventually fine).

scr.png

Just to clarify few things:

drag-and-drop doesn't work in WebKit

The above mentioned drag&drop was not (only) about WebKit, it was about being able to drag a file from the host system and drop it into a flatpak application.

Open With is just not possible under flatpak and Evolution should not be offering that

Evolution doesn't offer it and users miss it and users do not understand why it doesn't work, when they do have installed appropriate application. The extra step to pick the application in a new window/question doesn't work well for them. Aka bad user experience.

evolution-data-server being a system service with unstable API. ... These are kinda on the application developer

Right, right, I agree, it's up to the developers. In this particular case, I only wanted to exhibit that things can get difficult when the API changes. To be fair, the eds (D-Bus) API was stable for years. I made some giant changes and added some arguments to existing (D-Bus) functions and I do not expect any other (D-Bus) API changes to do in a near future, thus it may stay stable for the next (several) years again.

This doesn't make the point of "getting only 'half' of the fixes to the users when the Flatpak application depends on the host system eds" obsolete, it still applies, regardless eds' (D-Bus) API stability.

This discussion goes around long-term limitations of Flatpak and whether Flatpak benefits outweight them. But I'd like us to focus on the immediate problem:

Fedora flatpaks are currently offered to Workstation users as the default option although they still have fairly experimental nature with the following problems:

1) they're not localized,
2) they don't support deltas (updates are too big),
3) long-term sustainability of their maintenance is still in question (most Fedora flatpaks were created by one intern on our team, he won't certainly maintain them all in long term... what are the responsibility boundaries between flatpak and package maintainers... still a lot to figure out).

I think it's fine to have Fedora flatpaks enabled on Silverblue. There it's this or nothing (by default), but I'm strongly against making them default on Workstation because in the current state they break UX and expectations. We already receive bugs saying "why is Evolution suddenly in English when I use Norwegian and it has always been in Norwegian?"

So I suggest we make a change in Software to prefer RPM on Workstation again and put together a list of requirements Fedora flatpaks have to meet before they can be the default option. And once they meet them let's switch it back.

1) they're not localized,

I started looking into the localization issue earlier today. Should hopefully get this sorted out this week.

2) they don't support deltas (updates are too big),

Alex is working on this. There's a plan how to do delta updates.

3) long-term sustainability of their maintenance is still in question (most Fedora flatpaks were created by one intern on our team, he won't certainly maintain them all in long term... what are the responsibility boundaries between flatpak and package maintainers... still a lot to figure out).

I've been keeping them up to date (with the exception of libreoffice and evolution that are maintained by separate people). I agree that this doesn't scale, but just wanted to point out that they aren't unmaintained at all.

That's incorrect. The fedora flatpak repo has been enabled by default for the last two Fedora releases at least, maybe even more. And it doesn't need Workstation WG approval as it's not a third party repo.

tbh, I don't remember approving this. :/ I agree with Jiri, I'm not pleased that these are enabled before we have functioning debuginfo. We cannot support these flatpaks because we cannot get a backtrace when they crash. And because I use English, I didn't realize they were not localized; that's egregious.

Given that Alex is working on deltas and Kalev is working on localization, the only additional requirement I propose is debuginfo. If creating debuginfo extensions is difficult, then I think it would be acceptable to not split out debuginfo and just accept that the flatpaks will be big. But shipping without debuginfo is not OK.

(This comment applies only to Fedora. I understand different strategy may be required elsewhere.)

Evolution doesn't offer it and users miss it and users do not understand why it doesn't work, when they do have installed appropriate application. The extra step to pick the application in a new window/question doesn't work well for them. Aka bad user experience.

You're never going to be able to change this, because there is no portal to allow sandboxed applications to enumerate host apps... that would allow intrusive host fingerprinting, right? The most we should allow is for the user to select an app using the portal, to prevent the sandboxed app from seeing host applications. And we already have a portal for that: the OpenURI portal. So if you accept that we shouldn't allow the sandboxed app to see this much of the host system, it really requires a UI change in evolution.

So if you accept that we shouldn't allow the sandboxed app to see this much of the host system, it really requires a UI change in evolution.

There is nothing to be changed on the Evolution side, it already works as it is supposed to work. It's not even about me, I'm talking about users being used to some functionality and now they lost it for no obvious reason to them . You know where it leads, to a confusion and to a bug report. And then to explain them: "hey, no, Evolution works properly, you probably installed Flatpak, it cannot do it, bad luck for you". Some such not so funny comments. Again, I do not care, I only did have bug reports about it, thus I know it exists. Take it as one of the user experience issues I've been asked to provide above. Nothing more.

I accidentally installed Geary as a Fedora flatpak earlier this week. I was not impressed. Geary crashes often enough that I need debuginfo to be able to report bugs when it does, and Fedora flatpaks do not offer debuginfo. Users requiring localization would have been much worse off than me.

I think preferring flatpaks is a good long-term goal, and we should aim for this going forward. If particular applications don't work well as flatpaks, those applications should be fixed; that's an application problem, not an OS problem. But Fedora flatpaks are just not ready for end user consumption yet. We should walk this back for now.

I accidentally installed Geary as a Fedora flatpak earlier this week. I was not impressed.

Also: gnome-music and devhelp. For anyone who doesn't know English, this is a disaster. Meeting request.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

3 years ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

3 years ago

Are there experts who should be invited to this meeting? If so I'll do that, and push it back to June 28 (or their next available).

For anyone who doesn't know English, this is a disaster.

We should have the infra changes in place now to ship translations. I'm back from PTO now and will be working this week to rebuilt all the flatpaks we have to ship translations.

Are there experts who should be invited to this meeting? If so I'll do that, and push it back to June 28 (or their next available).

Experts: Owen, Kalev, Matthias

We're probably good to schedule this whenever. Pushing to next week seems fine if our flatpaks are going to be updated with localization support this week, but I'd still rather they not be exposed to end users before debuginfo is ready.

This was discussed at yesterday's working group meeting.

Resolving the translation issue is dependent on getting the module build service back up and running, so that needs to be our initial focus.

Debuginfo seems like a bigger challenge, largely due to the amount of infrastructure work that would be required. There's some upstream Flatpak work planned which could help with the situation.

What about the user experience for some applications? I agree it's not relevant for all applications, but some have better user experience (and desktop integration) when being installed by usual rpm means, instead of by Flatpak. Regular users might not notice the difference when installing, then they are surprised in the degradation of the functionality/integration.

Personally, I agree with the idea that Flatpaks have a lot to offer even on an package-based system, particularly in terms of the update experience and stability. However, to be viable, those Flatpaks do need to offer a comparable experience to their package-based equivalents.

Looking at this issue, it does feel a bit like we pushed out Fedora Flatpaks before they were fully baked, and it's still not entirely clear what needs to be done before we can be confident about the Fedora Flatpak story. Do we need a plan for Fedora Flatpaks, so we know what we're trying to achieve and what's required to get there?

One obvious concern is the state of the required infrastructure, but I also wonder about the level of public visibility.

Also, what's the story with the documentation? There's no mention of Fedora Flatpaks on the Flatpak Developer Portal page, and tracking is a giant wiki table, which hasn't seen much activity in about a year.

What about the user experience for some applications?

We skirted around that topic, but didn't address it directly, if I recall correctly.

My own (possibly naive) take would be that, if an app doesn't work well as a Flatpak, maybe it shouldn't be a Flatpak?

In my opinion we're getting ahead of ourselves with Fedora flatpaks and pushing something that is not ready for prime time to ordinary users.

It's not just about translations, debuginfo, and degraded experience with some apps, the whole infra and policies are not ready. Look at the current issue with the infra. Imagine users rely on Firefox flatpak and we're not able to push an update with critical security fixes to them for weeks. That is simply not acceptable for an OS we declare stable and for wide usage.

Also: almost all Fedora flatpaks are maintained by a handful of people on your team. I'm not sure if it's a viable situation long term. The bus factor is very low. Community involvement has been close to zero.

It's probably OK to have flatpaks as opt-in for now on the package-based Workstation, but there are quite a few things to figure out before we can declare them mature enough. And IMO it's not a matter of weeks or even months. So I'm proposing we switch back to packages by default on package-based Workstation.

BTW another problem is that both sources are called "Fedora", that's a bit unfortunate, I've already had several users telling me that they didn't know what was what. So calling one "Fedora packages" and the other "Fedora flatpaks" would be a good idea.

My own (possibly naive) take would be that, if an app doesn't work well as a Flatpak, maybe it shouldn't be a Flatpak?

The Flatpak build (in Fedora, in Flathub.org or even user's manual build with upstream-provided Flatpak manifest) has its use on systems with outdated dependencies (like Long Term Support distros). That is a very different story with compare of the distributions, which can make use of the rpm-packaged application. In other words, if RPM can be used, then use it, if it cannot be used (problem with the dependencies; the distro doesn't use/want RPM;...), then use Flatpak (which can have its price), to get the latest bits of the application.

It's not just about translations, debuginfo, and degraded experience with some apps, the whole infra and policies are not ready. Look at the current issue with the infra. Imagine users rely on Firefox flatpak and we're not able to push an update with critical security fixes to them for weeks. That is simply not acceptable for an OS we declare stable and for wide usage.
Also: almost all Fedora flatpaks are maintained by a handful of people on your team. I'm not sure if it's a viable situation long term. The bus factor is very low. Community involvement has been close to zero.

Indeed, I share these concerns. This is what I was getting at in terms of needing a plan.

We need to be realistic, both in terms of understanding what a viable solution looks like, and what we can achieve.

BTW another problem is that both sources are called "Fedora", that's a bit unfortunate, I've already had several users telling me that they didn't know what was what. So calling one "Fedora packages" and the other "Fedora flatpaks" would be a good idea.

Yes, it's known that the sources dropdown isn't great. It's been on my list to review it, but with GNOME Software development essentially stalled, it hasn't been a priority.

This was discussed at yesterday's working group meeting.
Resolving the translation issue is dependent on getting the module build service back up and running, so that needs to be our initial focus.

OK, that should be fixed now: the module build service is back up and running and I've rebuilt all the flatpaks and they are queued for testing in Bodhi.

(With the exception of evolution flatpak as mcrha was in the middle of doing a new build anyway.)

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

3 years ago

(With the exception of evolution flatpak as mcrha was in the middle of doing a new build anyway.)

Right, that one is finished successfully now as well.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

3 years ago

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

3 years ago

The discussion in the workstation working group got pretty wide-ranging here - to try to consolidate that discussion I'm taking an action item to write up a "status report" on Fedora Flatpaks ~two years in (https://blog.fishsoup.net/2018/12/04/flatpaks-in-fedora-now-live/)

A) What are our goals - for Flatpak in Fedora, and for Fedora-built Flatpaks
B) What improvements do we have planned or need?
C) What success have we had so far at creating Fedora Flatpaks and keeping them up-to-date. What can we do to improve the situation?

If we think that RPMs should always be preferred on an RPM-based Fedora, then all of that doesn't matter - but if we think that Flatpaks should be preferred "when they are good enough", then having a status report should help clarify our thinking.

If we think that RPMs should always be preferred on an RPM-based Fedora, then all of that doesn't matter - but if we think that Flatpaks should be preferred "when they are good enough", then having a status report should help clarify our thinking.

I think we have a rough consensus that flatpaks should be preferred by default, but there should be a way to configure gnome-software to avoid that.

Closing this issue. Please help by creating new issues for the many related items discussed today. There were too many for me to keep track of them all!

Metadata Update from @catanzaro:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

3 years ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting

3 years ago

I noticed it with the Evolution, after I (not really accidentally) made a Fedora Flatpak update for it [1]. This Flatpak version (the same as the one provided by Flathub.org) is very special, it runs in its own sandbox completely. It doesn't share the data with other applications, neither with GNOME Shell, and the way Flatpak is designed it adds a lot of limitations to the users. The current behaviour just breaks user experience.

My proposal for Evolution is that you should either fix Evolution to work better as a flatpak, or give up and stop building the flatpak (understanding that would mean no more Evolution in Silverblue). I don't think the Workstation WG needs to get involved in Evolution matters since it's not shipped by default anymore.

GNOME Software configuration stuff has been split out into #187

My proposal for Evolution is that you should either fix Evolution to work better as a flatpak

Well, those problems are not caused by the Evolution, as far as I know, ...

I don't think the Workstation WG needs to get involved in Evolution matters since it's not shipped by default anymore.

Sure, makes sense. Thanks for consideration.

Login to comment on this ticket.

Metadata
Attachments 1
Attached 3 years ago View Comment