Michael Catanzaro wrote:
Background info: In the Workstation working group, we're
currently
planning to allow replacing RPM packages for graphical apps with
Flatpaks. We're also planning to remove Fedora packages for selected
apps that are offered as Flatpaks by upstream. For instance, if
(hypothetical) Inkscape were to offer a Flatpak download on their web
site, the Inkscape developers could request that we remove the Inkscape
Fedora package and display their Flatpak in GNOME Software instead; the
goal here is to reduce friction between upstream and downstream that
people complain about so often, while ensuring it's still very easy to
find and install software that runs reliably on Fedora. I guess we
could do the same with snaps, if they become sufficiently popular, but
it'd be quite unfortunate to support two competing desktop
containerization solutions.
I find this completely unacceptable (no matter whether you end up using
Flatpak, Snap or whatever other flavor of containerized application format).
A container is NOT an appropriate replacement for a distribution package.
Containers necessarily bundle at least some libraries, thus coming with all
the drawbacks of bundled libraries: problems keeping up with security
updates, wasted space (bandwidth, disk and RAM), etc.
They will also never be supported outside of GNOME Software and MAYBE, if
you're lucky, some day, Plasma Discover. There are many more ways to install
applications: Apper, Yumex-DNF, the DNF command line, etc. I strongly doubt
those will ever support containers in an integrated way. (In fact, I hope
they won't. I don't want my package manager spammed with things that are
clearly not packages.)
Even if you use GNOME Software, there are still going to be major
differences in user experience depending on whether the package is actually
a Flatpak or an RPM, even if the UI tries to hide it from you. E.g., the
download time and the disk space requirements will necessarily be
significantly higher for the Flatpak. There may also be differences in user
experience due to the use of different libraries (different versions,
different patches applied, different build-time configuration, etc.). And
the sandboxing part of the containerization can also negatively affect the
user experience.
And whether we want to package an application as an RPM should always be a
function of whether somebody here in Fedora wants to package it, NOT of
whether upstream wants it packaged. If the license allows us to package the
software, and if we have people willing to do it, why would we let us get
terms dictated from upstream that are not part of the license and in fact
blatantly conflict with it?
I have also been pointed to this link:
http://kmkeen.com/maintainers-matter/
Kevin Kofler