Fedora remote falling behind in updates

I’ve posted this in other threads before so as to not make additional noise on the main page, but this continues to be an issue so was hoping I could draw some extra attention. Below is a comparison of commonly installed applications, and as you can see the fedora remote is behind flathub or the repo.

fedora remote
================

darktable                                org.darktable.Darktable                     3.6.0              stable
Evolution                                org.gnome.Evolution                         3.42.1             stable
Eye of GNOME                             org.gnome.eog                               41.0               stable
LibreOffice                              org.libreoffice.LibreOffice                                    stable
Firefox                                  org.mozilla.Firefox                         94.0               stable


flathub remote
================

Firefox	org.mozilla.firefox	95.0	stable
Evolution       org.gnome.Evolution     3.42.2  stable
Eye of GNOME    org.gnome.eog   41.0    stable <<< to be fair flathub version is no better
LibreOffice     org.libreoffice.LibreOffice     7.2.4.1 stable (fedora remote is 7.2.2.2)
darktable       org.darktable.Darktable 3.6.1   stable


Fedora repo
================

Name         : firefox
Version      : 95.0

Name         : evolution
Version      : 3.42.2

Name         : eog
Version      : 41.1

Name         : libreoffice
Epoch        : 1
Version      : 7.2.4.1 (fedora flatpak is 7.2.2.2)

Name         : darktable
Version      : 3.6.1

I used to replace all the pre-installed fedora remote flatpaks with flathub remote ones, but somewhere on here someone made me think this was the wrong way to go and to use a fedora remote flatpak if available. Recently though on an episode of Linux Unplugged they had the Endless OS director and he talked about how they used to have their own repository but now they try to publish to Flathub where possible.

I understand why Fedora uses its own repository, but if the apps don’t stay up to date then it would also be nice to have the option to go with Flatpak apps from the start. Just having the button available afterward isn’t enough… the fedora remote apps also have some weird update issues from time, so it makes it frustrating if I get the rare update available but it doesn’t work!

Great Observation :clap:
Some Developers are publishing directly to Flathub (LibreOffice, Blender etc.) so having the Flathub option is almost mandatory for keeping up with new packages. I believe Fedora packs it’s Flatpaks from the .rpm files but I could be mistaken.

While in practice this is true, the reason is the flatpaks installed on Fedora Linux via Fedora curated flatpaks are running on the Fedora Linux runtime for the particular release. With this effort by the Fedora community members involved, they are making the end use flatpak adhere to the release requirements just as any other package that you get from the standard Fedora Linux installation of Workstation or Silverblue. So you benefit as an end user from this effort. Even workstation edition is not 100% in sync of it’s upstream contributing projects that are packaged with it. So in that case, the upstream is often ahead of where Fedora Linux release current is, and therefore users will forever be faced with needing to get it from the source if they want it.

1 Like

Thanks for the reply @jakfrost and I definitely get the value add – the additional testing and commitment to free software. That is why I’ve endured some of the papercuts, like using the FF flatpak from the fedora remote even though it won’t play all the video I want.

But I just want the apps to be up to date. I actually reached out to Kalev Lember to see if there is anything I can do to be a part of the solution for that matter and not just complain about it haha

1 Like

Install ffmpeg flatpak. Fedora is not going to ship a browser with proprietary/DRM plugins…

@hamrheadcorvette I do have the ffmpeg extension, I pretty much keep up with all of the latest runtimes in the link below. But the problem is exactly that, Fedora flatpak remote does not use the runtimes found on flatuhb, it uses the org.fedoraproject.Platform runtime.

https://docs.flatpak.org/en/latest/available-runtimes.html

Again, I could live with the papercuts if at least the browser would stay up to date. I do flatpak updates each day in hopes to see one for FF, but it is still at 94 and now 5 minor releases behind (94.1, 94.2, 95.0, 95.1, 95.2).

I emailed to see if I could help and never heard back, and perhaps I couldn’t help anyway, but falling that far behind in the fedora remote just isn’t acceptable. It’s really a shame, if the software isn’t going to stay reasonably up to date you might as well let people one-click to replace all of it with Flathub. I’m going to be going through manually and replacing all of the apps.

I haven’t seen this, but I’m sure it is something people do. Though I will say that with the exception of knowing that Fedora-built stuff is going to be more strictly “FOSS” than something from Flathub which will include certain codecs/libraries that Fedora can’t, I just don’t see any reason why people would push you to install the Fedora-provided Flatpaks over the Flathub ones.

While not everything in Flathub is official (not by a long shot), there is a massive amount of applications there that are published directly from their authors, are consistently kept up to date, contain support for things that aren’t present in Fedora’s builds (like the aforementioned codecs), and overall have a wider userbase which means more testing as well.

Once Flathub is added, you might as well use it, IMHO.

BTW, here’s my flatpak list, and their repo/source. Almost everything is from Flathub.

This just came out An introduction to Fedora Flatpaks - Fedora Magazine great article.

Regarding the fedora flatpaks. I personally prefer them over flathub and the reason is the same as me not choosing rolling release distro like arch for example. Do you have the latest software available there ? Yes! Is it as stable as others ? Probably not.

One exception to this is proprietary stuff which I install from flathub where I don’t really have another choice other than layering these things from copr or external repo.

I rather have slightly delayed updates to fedora flatpak and stable desktop experience which is the reason I’m using Fedora. I used to distro hop for many years and I always came back to Fedora for stability. And if there are any bugs with fedora flatpaks, I try to report them as it’s likely it’s also affecting users who don’t use flatpaks but standard RPM (Fedora workstation etc).

What I like here is that I’m given a choice. And If I want to use flathub… I can :slight_smile: No one is forcing me. If I have to wait 2-3 weeks before newer version of software appears in fedora flatpaks ? That’s fine I trust fedora built stuff. After all Fedora being famous for stability is not coming from thin air.

PS. Are fedora flatpaks perfect and without bugs ? Surely not! But I’m getting all of this great stuff for free! If I spot the bug, I report it. That’s the least I can do to help others if I don’t have the powers to fix those bugs by myself.

I don’t see how Fedora packaging an upstream app for flatpak is more stable than flathub. Is Fedora also patching for bugs or does Fedora do rigourous testing to make sure it is stable before releasing it? Patches should be sent upstream anyway. What does “stable” mean anyway? If anything the Fedora repo is more likely to be less secure if it is too far behind upstream.

1 Like

It gets built against the Fedora runtime for one thing. Stable as everything that is packaged with Fedora Linux within the same release criteria.

These aren’t parallels. Considering that Flatpaks have consistent access to the proper version of runtimes they need, while on Arch everything is changing including this. The stability of the programs is not determined simply by whether or not you wait a couple of weeks for them, because they already have exactly the necessary components they expect upon launch.

Not to mention that, again, Flathub has a much broader testing bed than the Fedora remote does.

It is fair enough that you would prefer Fedora Flatpaks, but I definitely still don’t think anyone should push one over the other as the OP said happened to them.

Do you see anyone pushing you?

I like the way fedora manages software in RPMs and I also like those being flatpaks. It makes complete sense to have those as defaults. If you don’t like them you can use flathub or other remote. It’s that simple

No, that was just the basis of my original statement, which is why I mentioned it again.

The OP topic identified the issue as Fedora flatpaks not keeping up to date with the latest upstream. Well, why is that? In the Fedora flatpak build process, flatpak packages are built from the Fedora RPM packages. RPM packages depend on other RPM packages. So to release a new Fedora flatpak all the dependent RPMs must be up to date. It takes RPM package maintainers time to update these and make sure they all work together. Also, RPM dependencies must also work with other apps and it may not be possible to update to the latest dependency without also updating the other dependent apps. Flathub pulls its app sources and dependencies from upstream repos and builds the updated flatpak. Flathub app maintainer needs to update the manifest and test the build. So it seems to me it is much easier to keep up to date with that process. So the Fedora flatpak release delay is a systemic problem by design and difficult to solve. The choice to build Fedora flatpaks from RPMs was intentional but I do not know the background behind that decision. IMHO, I believe that Fedora should only package flatpaks for the absolute minimum needed apps that cannot be used directly from Flathub like how Endless OS is doing. Fedora should be focused on delivering a quality base OS platform that these containerized apps run on. In the future, RPM based app packaging may become less common as flatpaks replace them.

1 Like

I would agree to above but perhaps in about 5-10 years when flatpaks/flathub will become more mature. There is all sorts of stuff created using many different methods ( one of them is literally transplanting .deb packages into flatpaks)

Until then I’m still going to be appreciating flatpaks built from RPMs. Not only for stability but for the fact that I know for sure that the software I’m installing from there has been properly vetted ( there is number of vetting processes involved before something becomes available as RPM in fedora, including it going through legal departments etc )

I also saw somewhere that fedora has an includelist of some flatpaks from flathub which are considered “safe” enough to be included by default in fedora.

Everything takes time. But just like people have their opinions about fedora remote… I have mine about flathub and I’m personally staying away from it unless I absolutely have no other choice.

PS. You can check yourself here how many apps are basically debian packages transplanted into flatpaks Sign in to GitHub · GitHub

Also I strongly believe flathub should split into flathub official and flathub community remotes.

The official would contain only flatpaks built and maintained/supported by the app creator. Being built to standard ( not transplanting deb packages or something else ).

1 Like

Yes, I believe Debian packages would have the same dependency issues as Red Hat packages in building a flatpak. As you say, flatpaks will take time to evolve. To improve the Fedora update delay issue the only actions that I can see in the short term is for packagers to make timely releases and maybe some automated tools to monitor and notify updated release version status. Also, look for ways to streamline the Fedora build pipeline and maybe have some prioritized apps like web browsers where timely security updates are critical. Also, popular apps where new features and bug fixes are coming out often could be prioritized. What other actions can we take to improve the problem?

1 Like

I would first try to determine if there is an issue at all.

Is there any examples of outdated packages ?

You’re correct. The claims need to be verified to understand if this is a short term event or a chronic issue. Maybe it is not really a problem that needs action right now.