Fedora, FFmpeg, Firefox, Flatpak, and Fusion [LWN.net]

By Jonathan Corbet
June 16, 2022

Fedora's objective to become the desktop Linux distribution of choice has long been hampered by Red Hat's risk-averse legal department, which strictly limits the type of software that Fedora can ship. Specifically, anything that might be encumbered by patents is off-limits, with the result that much of the media that users might find on the net is unplayable. This situation has improved over the years as the result of a lot of work within the Fedora project, but it still puts Fedora at a disadvantage relative to some other distributions. A recent discussion on video support, though, shines a light on how some surprising legal reasoning may be providing a way out of this problem; that way may not be pleasing to all involved, however.

FFmpeg and Firefox

At the beginning of June, Otto Urpelainen posted (on the Fedora development list) about some surprising behavior he had observed on his system. Initially, the Firefox browser was able to play the videos he wanted to watch. Installing Fedora's ffmpeg-free package, though, caused those videos to fail to play. As Urpelainen noted: "This is unexpected, because one would expect that installing any variant of ffmpeg would improve video support, not degrade it".

As Kevin Kofler pointed out, this behavior looks like a bug in Firefox, which is unable to find the OpenH264 variant of the H.264 decoder found in the ffmpeg-free package. But it was not lost on anybody that this problem does not occur if the version of FFmpeg shipped by RPM Fusion is installed instead, and that the H.264 codec found there doesn't require the various convolutions required to get OpenH264 onto Fedora. The H.264 support in RPM Fusion is thought by some to work better as well. For this reason, Vitaly Zaitsev said that the proper solution is for users just to enable RPM Fusion.

Michael Catanzaro took issue with that advice:

Vitaly, your suggestions to enable rpmfusion are not helpful for inexperienced Fedora users, who expect multimedia to work out-of-the-box. Common multimedia needs like "play a video" absolutely need to work without rpmfusion, and we need Fedora developers testing this to make sure it works.

But Kofler replied that "It is common knowledge that Fedora is/was effectively useless for anything remotely related to multimedia without RPM Fusion packages". Zaitsev doubled down later by saying that Fedora should simply preload the RPM Fusion repository so that users need not go through the process of learning that they need it and figuring out how to enable it themselves.

That is the process that is required now; a new Fedora installation will not be set up to obtain packages from RPM Fusion and will not help users understand that, sooner or later, they will have to configure that repository. But fixing that problem still does not appear to be in the works; one of the constraints placed on the Fedora project is that it cannot help users find repositories containing code that, for example, might have patent problems in some jurisdictions. This "pretend it's not there" approach has led to a certain amount of frustration over the years.

Enter Flatpak

More recently, though, there has been a development on a related front. In June 2021, the project adopted a proposal to set up the Flathub repository by default on Fedora systems. Flathub is, like RPM Fusion, an independent repository (run by the GNOME Foundation) and, again like RPM Fusion, it contains software that Fedora cannot distribute, but it distributes packages in the Flatpak format rather than using RPM. There is a push within Fedora to ship applications as flatpaks rather than as RPMs. Flatpak makes dependency management easier and, in theory at least, can run applications within secure sandboxes, but many developers see the format as inferior and would prefer to avoid it.

The Flathub repository was set up in a "filtered" mode, meaning that only applications that were acceptable to Fedora would be available (by default), but that still left room for proprietary flatpaks like Zoom, Microsoft Teams, and Minecraft. Last April, though, the situation changed: permission had been received to drop the filtering and present the full Flathub repository to users. Fedora developers are currently working on enabling this change for the upcoming Fedora 37 release. Catanzaro welcomed this news:

Er, so everything from Flathub is fine now, no restrictions? Seriously great news. In this case, I'd say priority one is to stop shipping Fedora's Firefox and Totem altogether, and default to getting them from Flathub instead.

Not everybody was so joyful, especially given that the plan is to have the system select a flatpak package over a traditional RPM package when both are available. Deferring to an outside repository for important packages like Firefox is also not universally accepted as ideal. But the idea that Fedora can now freely set up access to an external repository with software that Fedora cannot ship itself is generally welcome. It could be a solution to Fedora's longstanding limitations with regard to problematic media formats.

Why not RPM Fusion?

Since that decision was made, developers have been asking if access to RPM Fusion could be preloaded in Fedora as well, always to be told that it is not possible. The question came up again in this conversation as well; Catanzaro responded:

For avoidance of doubt, Fedora Legal has decided we may use flathub but not rpmfusion. As I explained to you previously, they have also decided not to share their reasoning for this.

Fedora project leader Matthew Miller answered with a pointer to this explanation:

Flathub is a third-party repository which provides software for various Linux distributions. It doesn't shape what software it carries around what Fedora does not. It fundamentally exists to solve a problem with Linux app distribution to which our policies around licensing, software freedom, and etc., are incidental. This makes it a different case.

It is fair to say that not everybody finds this explanation convincing. Kofler described it as "an absolutely ridiculous double standard". "Maxwell G" called it "a pretty flimsy argument". Petr Pisar tried to explain the difference: RPM Fusion specifically targets Fedora, while Flathub is not Fedora-specific, and that somehow makes a difference.

The logic behind this policy surely makes sense to somebody in Red Hat's legal department, but it may have some unfortunate consequences in the Fedora user community. It is not hard to imagine that it could be causing a lack of morale among the RPM Fusion developers, who have worked for many years to address a key shortcoming in Fedora systems. If Fedora pushes its users toward the Flathub solution, RPM Fusion may eventually just give up, leaving no alternative to Flathub, which is a less-appealing repository for many. It is not at all clear that Fedora and its user community would be better off in that world.

to post comments

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 15:32 UTC (Thu) by amacater (subscriber, #790) [Link] (4 responses)

This reminds me very much of the ongoing discussion round firmware in Debian (and past discussions around Debian multimedia codecs). Fedora and Debian have taken slightly different lines on firmware: a couple of packages in Debian are not there in Fedora for example (Broadcom fwcutter springs to mind) but both distributions are trying to be maximally free and maximally useful to users.

Every distribution has different policies: there might be scope for sitting down and agreeing a common policy between several distributions so as to avoid users distro-hopping just because "Distro A provides XYZ and distro B doesn't."

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 22:19 UTC (Thu) by ballombe (subscriber, #9523) [Link] (3 responses)

distro-hopping is the whole point to have different distributions.
Having more users means more support cost, so it is not always a positive.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 23, 2022 15:56 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

Those policies are crafted, at least partially, based on the legal risks that the publishers of the distros are willing to accept. Thus, any 'common policy' would likely to have to be the lowest-common-risk among all of the distros, and most of their users would be unhappy.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 23, 2022 20:13 UTC (Thu) by pebolle (guest, #35204) [Link] (1 responses)

> distro-hopping is the whole point to have different distributions.

The whole point of distributions, or better their cause, appears to be the narcissism of small differences. (Perhaps that's one of the few worthwhile contributions of Freud?)

I find the deb versus rpm, KDE versus GNOME, systemd versus the fossils, and whatever other splits very depressing. I almost have sympathy for Google here: Android has been a take-it-or-leave-it offering from the get go. (Yes, it helps if you make a few billions every month. It helps even more that your market share is not below the rounding error of measurement.)

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 30, 2022 12:59 UTC (Thu) by callegar (guest, #16148) [Link]

... but Android has at least as many variants as Linux desktops do: One UI, MIUI, EMUI... just to mention a few. All with different feature sets (e.g. in MIUI you cannot pin apps, so giving a phone to a kid to play gcompris is a huge issue). It is almost impossible to "switch" phone brand for many users without getting utterly confused.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 16:18 UTC (Thu) by bferrell (subscriber, #624) [Link] (1 responses)

To be a thing "of choice" is usually more about stability than who might get sued. Fedora's desire to be not JUST "of choice", but more importantly seen as "bloody edge" is it's real limiting factor.

No one wants to adopt a tool that may or may not work with every update. There are other distros doing this too... All wanting to be FB "move fast! Break things!"

There is even question rising among the kernel devs if things might not be moving too fast now.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 16:40 UTC (Thu) by farnz (subscriber, #17727) [Link]

Part of the problem is that people do want things to move fast. But they also want things to not move; if things work as they're happy with, then those things should not change, while things that don't work well need to move fast to newer versions. And as the set of things that some people are happy with overlaps the set of things that some people think don't work well, we have a tension to resolve.

Fedora's resolution is to basically trust that upstream's pace is acceptable; RHEL's resolution is to try and hold on very stable versions for a long time.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 16:36 UTC (Thu) by lobachevsky (subscriber, #121871) [Link] (5 responses)

I'm running the Flatpak version Firefox on Debian as my main browser due to Debian's policy keeping Firefox users on semi-outdated ESR versions while Chrome users get the current release (or one that is dangerously outdated). This works mostly fine, but it still has some seriously rough edges. Fonts on Github look terrible [1], even with the sandbox relaxed so that one can save files outside of Downloads the paths shown in the file chooser are seriously screwy and sometimes still go through flatpak's bind mounts and at times files I saved just wouldn't appear in the directory I saved them to (can't seem to reproduce that now) and, somewhat annoying for larger deployments, host config files are difficult to get into the flatpak.

Nothing making this unsuable and definitely better than an outdated Firefox, but I'd be wary of deploying this to users on a large scale yet.

[1] https://github.com/flatpak/flatpak/issues/4571
[2] https://github.com/flatpak/flatpak/issues/4525

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 12:43 UTC (Fri) by daenzer (subscriber, #7050) [Link] (1 responses)

FWIW, current Firefox is available in Debian sid. It can be installed on an otherwise Debian testing system.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 18, 2022 10:20 UTC (Sat) by lobachevsky (subscriber, #121871) [Link]

Alas that's of no help if you're forced to run stable.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 7:18 UTC (Sun) by gspr (subscriber, #91542) [Link]

What's so horrible about Firefox LTS? I personally love that my browser (and every other package!) doesn't wildly change every month or so.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 23, 2022 15:58 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

Same here, and those issues still exist. I can reproduce the 'downloaded file disappears' problem at will, since I often try to save files directly to an SMB share which I navigate to using the file chooser... and then the file does not get put there. I've resorted to just letting everything go to 'Downloads' and moving them later, which I hate.

There have also been ongoing problems with CUPS access from the Flatpak Firefox, so much so that I gave up trying to directly print from the browser and instead Save to PDF then open that PDF and print it.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 30, 2022 13:08 UTC (Thu) by callegar (guest, #16148) [Link]

I have tried the "snap" version of firefox in the latest ubuntu and I must say that everything works amazingly well... apart from those things that don't work and fail in incredibly irritating ways: like broken grouping in the plasma task bar, poor fonts, firefox not starting if you try to start it from the cli from a directory it does not like, inability to access stuff that lives out of your home or media (it is not that you cannot access them by default... there is nothing you can do to allow such access), inability to customize things like mime types, broken extensions (markdown viewer), ecc. Glad there is still a PPA with a non snap version of firefox. I hope that the flatpack version provides a better experience.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 16:54 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

Just learned about two repositories in a single article, and it looks like there is interesting stuff there :-)

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 16:55 UTC (Thu) by cyperpunks (subscriber, #39406) [Link] (12 responses)

One of the few things Linux distros does much better than Windows, macOS and the legacy UNIX platforms are the package repos and package management tools.

Moving this success story to new formats as Flatpaks and Snap are very risky business.

Packaging of software is a very complex topic, moving to new formats don't make that problem go away, there are no free lunch.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 8:49 UTC (Fri) by taladar (subscriber, #68407) [Link] (9 responses)

Agreed. Flatpak and similar ways of packaging software feel very much like making the hard problems with packaging go away by letting someone do it who is completely ignorant of most of them (the developers), not by actually solving them.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 17:04 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (8 responses)

Also it makes it incredibly difficult if not impossible to actually update individual libraries when (not if) a security vulnerability happens.

Instead of waiting for your distro to ship an updated OpenSSL... now you need to wait for every containerized package to ship an updated image entirely.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 18:36 UTC (Fri) by farnz (subscriber, #17727) [Link] (7 responses)

At least in the case of Flatpak, that's a false statement - you should be using OpenSSL from a runtime, like org.freedesktop.Platform, and as soon as that runtime is updated, you've got an updated OpenSSL in all Flatpaks using the runtime.

The difference between Flatpak and a normal distro is the granularity of dependencies; with Flatpak, my dependencies come in coarse-grained lumps (the runtime I choose, and any runtime extensions I add), rather than in the fine-grained set a distro gives you. And I'm expected to bundle dependencies that aren't in a runtime.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 20:10 UTC (Fri) by intelfx (subscriber, #130118) [Link] (6 responses)

> you should be using OpenSSL from a runtime, like org.freedesktop.Platform, and as soon as that runtime is updated, you've got an updated OpenSSL in all Flatpaks using the runtime

Is that so? Don't flatpak applications "bind" to the specific runtime version/hash they were built against, so that the resulting rootfs is immutable?

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 22:37 UTC (Fri) by dbnichol (subscriber, #39622) [Link] (5 responses)

No, they're just bind mounted together read only at runtime. An app binds to a particular branch of a runtime, but the particular commit that points to can change.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 21, 2022 1:32 UTC (Tue) by WolfWings (subscriber, #56790) [Link] (4 responses)

But that's what I meant originally: You're stuck waiting for the package that calls OpenSSL to update to reference the newer OpenSSL version or verifying they're not version-locked... you can't just update the system-wide single OpenSSL install and know you're done with it.

It moves the version-tracking load to the SysAdmin much more heavily having to know about everything instead of just updating the actual vulnerable package once and done, which is literally the entire point of ABIs and APIs that don't wildly change.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 21, 2022 1:58 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

No, you're not. Flatpaks depend on runtimes like 21.08, and 21.08 then gets updated with security fixes.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 21, 2022 9:50 UTC (Tue) by kleptog (subscriber, #1183) [Link] (1 responses)

That's actually a neat trick. Sometimes it would be useful to be able to replace layers in Docker images with updated versions without having to rebuild the whole thing. The standard tools don't really support this.

Of course, it's affects your reproducibility, since the image as run might not exactly match the image if you built it again. But if you're careful with the updates this should work quite well.

This article has raised my appreciation of Flatpak somewhat, which wasn't what I expected.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 21, 2022 16:57 UTC (Tue) by dbnichol (subscriber, #39622) [Link]

The freedesktop runtime (as well as the GNOME runtime) is built with BuildStream, which is pretty solid with reproducibility by using a distributed object cache. Also, since the flatpak distribution method is ostree and therefore file level, there are immediate benefits of reproducibility since there smaller updates. For that reason, the runtime developers seem keen to add reproducibility fixes.

https://gitlab.com/freedesktop-sdk/freedesktop-sdk
https://www.buildstream.build/

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 21, 2022 9:35 UTC (Tue) by farnz (subscriber, #17727) [Link]

No - you update the runtime that contains OpenSSL to a new patch version, and all Flatpaks that depend on that runtime pick up the update automatically when they're next restarted. This is exactly the same level of complexity as updating OpenSSL by updating a single .deb, but with the proviso that the amount of data to transfer could be larger (since you're updating a whole runtime, and therefore picking up other fixes, not just targeting an OpenSSL fix).

You still face the problem of applications that are tied to runtimes that no longer get security updates - but that's a similar level of admin burden as handling applications that only link against unsupported OpenSSL versions, where you need to backport a fix from the version of OpenSSL in Debian Buster to the version that shipped with Debian Potato, or update the application to a newer version that runs on a newer runtime, or remove the application.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 17:03 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (1 responses)

That was true, but after working with https://docs.microsoft.com/en-us/windows/package-manager/... some on my Windows 10 and 11 laptops I'm actually floored by how comprehensive of a package manager MS is shipping now for CLI use.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 18, 2022 21:55 UTC (Sat) by alsuren (subscriber, #62141) [Link]

Seconded. The linux packaging story that we've learnt to put up with for decades is far from perfect. Linux distros can't afford to sit on their laurels, because the other major platforms have caught up.

The situation on MacOS used to be very fragmented, with macports, fink, and a few others. It now seems to have settled down to everyone using homebrew. It's a manual step to set up that non-technical users wouldn't be expected to do, but I would be willing to bet that there are more users of homebrew than users of any one package manager under desktop linux (I might just need to get out of my bubble. How would I find that out?).

I think that flatpak represents an opportunity for desktop linux to leapfrog the other platforms in terms user experience again. The sandboxing capabilities of modern linux have already unlocked a developer experience (in the form of docker, devops and more recently vscode devcontainers) that I never thought was possible when I started my first dev job at Collabora, a decade ago. We can do the same thing for desktop user experience too, and I'm glad to see it progressing so well. Maybe it will make me switch back.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 21:01 UTC (Thu) by Seq (guest, #110060) [Link]

I can see the concern from a technical point of view regarding rpm-fusion when compared to flathub.

Packages installed from there modify the system, and work as dependencies for other software. There may be concerns about timeliness of security updates. There have also been scenarios where rpm fusion hasn't been ready to go in-sync with Fedora version upgrades, thus either failing the upgrade or causing breakage. I've dealt with these issues in the past, but I made an informed decision to use and enable rpmfusion. Applying this to users with a mere checkbox (or by default?) and without the knowledge/ability to fix issues would be a concern. Granted, rpmfusion has improved on the timeliness issue a lot in recent years, possibly due to using similar infrastructure to Fedora now (Koji, etc).

Flathub, by comparison, are just bolt-ons that won't break the system itself.

(This doesn't address any legal concern, which is slightly more iffy. I haven't made up my mind on that).

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 16, 2022 23:31 UTC (Thu) by willy (subscriber, #9762) [Link]

I think the developers who are criticising the lawyers probably do not understand the concept of Colour.

https://ansuz.sooke.bc.ca/entry/23

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 8:47 UTC (Fri) by rsidd (guest, #2582) [Link] (3 responses)

Fedora seems to be going the flatpak route for legal reasons; meanwhile Ubuntu went for a snap-only Firefox for convenience reasons (and supposedly because Mozilla too preferred to support a snap).

There is an annoying bug in pdf rendering in the Ubuntu snap which doesn't occur in the apt-based firefox-trunk (including older versions). It looks maybe as if the snap is not able to find system fonts, analogous to the H.264 codec issue in the article. I wonder if a flatpak firefox on fedora will have its own issues.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 9:58 UTC (Sun) by fredrik (subscriber, #232) [Link]

It is still possible to install a Firefox version from a deb package rather than as a snap on Ubuntu 22.04. It is maintained by the Ubuntu Mozilla team.

https://launchpad.net/~mozillateam
https://balintreczey.hu/blog/firefox-on-ubuntu-22-04-from...

It is also still possible to remove snap/snapd entirely from Ubuntu 22.04. In case you do not like such newfangled contraptions on your computer.

https://haydenjames.io/remove-snap-ubuntu-22-04-lts/

I hope this will continue to be possible for years to come, both options are entirely to my taste.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 23, 2022 12:39 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

This was really more early brainstorming than something that's actually going to happen. It's unlikely that we'll actually switch Firefox and Totem to using flatpaks from Flathub by default. I was pretty frustrated with OpenH264 when I suggested that.

It's very likely that we'll switch *everything* to use Flatpak sooner rather than later, but they would still be built by Fedora and not have access to any multimedia goodness beyond what's already available in Fedora.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 27, 2022 8:44 UTC (Mon) by danielthompson (subscriber, #97243) [Link]

> Fedora seems to be going the flatpak route for legal reasons; meanwhile Ubuntu went for a
> snap-only Firefox for convenience reasons (and supposedly because Mozilla too preferred
> to support a snap).

I don't think this is right. flatpak is useful to Fedora to convenience reasons. That is the difference (compared to rpmfusion) that allows them to include it. Having useful not-a-legal-workaround purpose to providing flatpak support in the distro is enough to change the legal reasoning about whether to include it by default. The same legal reasoning cannot be applied to rpmfusion because this repo arguably only exists for legal reasons.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 15:05 UTC (Fri) by eru (subscriber, #2753) [Link] (1 responses)

Ffmpeg (its libraries and/or the whole binary) is used as a building block in many multimedia applications. With a Flatpak or Snap distribution, every application using ffmpeg will ship its own copy. I find this sort of thing distasteful.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 17, 2022 15:14 UTC (Fri) by farnz (subscriber, #17727) [Link]

Not with Flatpak - the org.freedesktop.Platform runtime provides media codecs using FFmpeg, and if you need more than the "standard" set, you can add the org.freedesktop.Platform.ffmpeg-full runtime extension to get all codecs FFmpeg supports.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 18, 2022 23:56 UTC (Sat) by elagost (guest, #159111) [Link] (1 responses)

Fedora can ship a repo with ffmpeg, VLC, and mpv, but can't ship a different repo for ffmpeg, VLC, and mpv. Just because one's multi-distro, and the other's for Fedora specifically.
If a fresh install can obtain both the aforementioned programs as well as Nvidia Drivers and Google Chrome, then there's no reason not to bake in RPMFusion - even if just the free repo and opt-in; free/non-free are separated. ffmpeg is ffmpeg, regardless of if it's in /usr/bin or /var/lib/flatpak.

I have used exclusively Fedora for years and strongly prefer it for many reasons, but I would go elsewhere immediately if RPMFusion's repos were no longer available. They are essential for my desktop and servers.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 20, 2022 10:46 UTC (Mon) by farnz (subscriber, #17727) [Link]

It makes sense in terms of legal risk: there are a variety of mechanisms you can use as a plaintiff to persuade a court that an apparently independent legal entity is in fact the defendant using a second entity at arm's length to escape liability. It appears that Red Hat's legal team think that defending the idea that RPM Fusion is separate to the Fedora Project would become too challenging for the level of resource they're willing to spend on Fedora, but that defending the idea that FlatHub is separate to the Fedora Project would not.

We can all speculate on why RH Legal think this way - I think the cross-distro nature of FlatHub, as compared to the tight dependencies from RPM Fusion on Fedora is a big component, personally - but for as long as the Fedora Project is a "A Red Hat-Sponsored Community Project", Red Hat Legal's willingness to take that risk is going to matter.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 18, 2022 23:57 UTC (Sat) by bojan (subscriber, #14302) [Link]

Flatpak and similar, including some of the container stuff, just seem like a decision to move agreement on what should be around an application to another place. Linux distros cannot even agree on basic package format, let alone how library versions should be done etc. So, instead, more layers are slapped on, in an effort to avoid agreeing on things.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 7:31 UTC (Sun) by gfernandes (subscriber, #119910) [Link] (6 responses)

One does wonder if Flatpak is a solution in search of a problem. When one has a hammer (container runtime), every problem begins to look like a nail (container).

But one should be wary of this approach.

Flatpak advertised itself as a distribution *agnostic* packaging solution. The only way this can be possible is to do the *very* thing Windows installable have been doing for ages - bundle all dependencies in each installable.

This is the *very* thing Linux users prided themselves on - our shared library model that allowed all users of the same dependency, to *not* need to bundle that dependency in their installable bundle.

Given that Flatpak runtimes _can_ be shared, but does anyone know how many actually *are*?

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 17:10 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (5 responses)

> The only way this can be possible is to do the *very* thing Windows installable have been doing for ages - bundle all dependencies in each installable.

You mention runtimes, which means you're aware that this is not the only way this can be possible - most common dependencies exist in the runtimes and aren't bundled with apps.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 22:14 UTC (Sun) by gfernandes (subscriber, #119910) [Link] (4 responses)

This is why I also asked for statistics on how many runtimes are actually shared.

The _ability_ to share does not automatically translate into reality.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 22:22 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (3 responses)

I'm sorry, I don't quite understand the question. What do you mean by "How many runtimes are actually shared"? Most Flatpaks I have installed depend on org.freedesktop.Platform, with one (the only Gnome app I have installed via Flatpak) depending on org.gnome.Platform.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 20, 2022 6:35 UTC (Mon) by gfernandes (subscriber, #119910) [Link] (2 responses)

Thank you. That is exactly the information that would guide any decisions, or resolve misconceptions around dependencies and sharing.

What you have said makes it sound like a fair option.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 21, 2022 17:26 UTC (Tue) by dbnichol (subscriber, #39622) [Link]

See https://docs.flatpak.org/en/latest/available-runtimes.html. People are generally discouraged from rolling their own runtime for exactly the reuse fragmentation you mentioned, so most apps are based on those. https://docs.flatpak.org/en/latest/dependencies.html discusses this as well as the other tradeoffs.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 23, 2022 12:49 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

Basically there is the freedesktop runtime, the GNOME runtime, the KDE runtime, and the Fedora runtime. Probably more that I don't know about, but those are the big ones. The GNOME and KDE runtimes are both based on the freedesktop runtime.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 19, 2022 16:28 UTC (Sun) by marcH (subscriber, #57642) [Link] (2 responses)

> Not everybody was so joyful, especially given that the plan is to have the system select a flatpak package over a traditional RPM package when both are available.

What front-end(s) is this preference implemented in? I had a (too) brief look at the page linked and saw a reference to some obscure "GNOME software". What about "dnf" for instance?

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 20, 2022 9:16 UTC (Mon) by seyman (subscriber, #1172) [Link] (1 responses)

"GNOME software" is Gnome Software.

As for dnf, the only type of package it knows about is rpm. It has no idea what flatpaks are and cannot install them.

Fedora, FFmpeg, Firefox, Flatpak, and Fusion

Posted Jun 23, 2022 15:55 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

This behavior is not unique to Fedora; if you enable Flathub on a Debian GNOME system, GNOME Software will often show Flatpak results in preference to APT repository results when a user searches for applications. Both are available, but GNOME Software will default to installing the Flatpak if the user just clicks the 'Install' button.