Daniel P. Berrangé wrote:
Looking at Flatpaks with both my upstream author hat and distro
maintainer
hat, the main advantages I see is not the isolation. It is that they have
the potential to eliminate the massive amount of duplicated work between
every distro re-packaging the same app, and ensure more timely availablity
of new releases to end users by de-coupling from the distro release cycle.
But that comes at the cost of "lowest common denominator" (*) packaging with
bundled dependencies (at least those not included in the runtime), inability
to use distro-specific compiler flags (e.g., you either always build with or
always without frame pointers, independently of what the user's distribution
prefers), less system integration (also due to the isolation), etc.
As an upstream author, I want the latest releases of my software to
be
available for users to install as quickly as possible. Distros largely
aren't satisfying that desire as well as I would like. If I rely on
distro packaging, there can 3-12 month delay before a distro gets my
new release in front of a user depending on their release cycle.
Users of non-rolling-release distros do not necessarily *want* to get
upgraded the latest major version of your application (with, e.g., major UI
changes) at an unexpected point in time at which they just want to get work
done. (And just not upgrading Flatpaks is also not a good idea because of
security.)
Where it makes sense, distro-provided opt-in PPA mechanisms such as Copr,
OBS, Launchpad PPAs, etc. can be used (but sure, it is yet another place
where the application needs to be packaged, that is the drawback).
The tragedy would be if every distro ends up re-doing the
creation and shipping of flatpaks, just as they do today
with the distros specific packaging formats.
Is that not exactly what Fedora Flatpaks are about?
Kevin Kofler
(*) I know this term ("lowest common denominator") is mathematically
nonsense. There is only a least/lowest common multiple and a greatest common
denominator in mathematics. :-)