----- Original Message -----
Hi Bastien,
Here are some of the benefits I see of this effort as compared to simply
telling users to consume Flatpaks from Flathub or independent repositories:
Sorry it took a couple of days to get back to you.
If the end-goal is shipping Flatpaks, and that those Flatpaks need to be built
on Fedora infrastructure to be distributable, then we have some other options.
* Benefit to Flaptak users on all distributions: more applications
are
available more quickly. Some applications will be much easier to create
Flatpaks of this way because of their build dependencies. For lightly
maintained, older applications, building a Flatpak of an RPM within Fedora
is simple and avoids creating another independent place that someone has to
keep an eye on.
For older, mature or not well-maintained, applications, I would think that
having them available through an upstream Flatpak would be more viable, sharing
maintenance with other distributions.
* Benefit to Flatpak users on all distributions: this works towards
having a
runtime (whether Fedora or RHEL/CentOS based) that has a long lifetime and
strong security update guarantees
Having a long lifetime and strong security update guarantees is also a goal
of the Flatpak Freedesktop SDK and runtime.
* Benefit to Fedora users: they can get Flatpaks and runtimes from a
source
they already have trust in.
OK.
* Benefit to Fedora users: this is a repository of Flaptaks we can
enable by
default (there are ongoing discussions of splitting up Flathub, but
currently it combines both content that Fedora can point users to, and
content that is problematical from a legal or Free Software point of view,
all mixed together.)
Seems that this problem is being worked on then.
* Benefit to Fedora contributors: they can work within the community
and
infrastructure they are already familiar with to fill gaps in the set of
available Flatpaks.
Sure, it avoids creating more accounts, but the tooling is so different that
I don't think that it's going to help much.
* Benefit to Fedora contributors: they can make their packaging work
available across distributions and distribution versions.
Most likely duplicating upstream work on getting that same
* Benefit to upstream: if they already have a good relationship with
Fedora
and their application is well maintained there, they can point users on all
distributions to a Fedora Flatpak.
* Benefit to Red Hat: We build infrastructure technology and content that we
can take into the RHEL context and make runtimes and Flatpaks available to
our customers with the type of guarantees that we are already providing for
RPM content.
That doesn't seem to require
LIke many things we do in Fedora, the benefit to RHEL is a big reason
that
we've been doing this work, and was an influence in some of decisions about
how things were implemented, but I think the work does stand on its own as
useful to the Fedora and Flatpak communities.
In summary, I think that building Flatpaks from Fedora binary RPMs in Fedora
infrastructure is not the right path forward:
- long-term supported runtime and SDK is a good thing, no questions, and that
can probably be generated on Fedora infrastructure, as it shares so much
with the Fedora OS itself
- Building Flatpak from binary RPMs is a bad idea. In Flatpak, you'd want the
app dependencies (the ones that aren't part of the runeimt) to be as closely
configured to what the application needs as necessary. That means that one
applications might disable 99% of a library just to have the one plugin it
needs to run, that wouldn't be possible when building from a binary RPM. That
also means that the application is impacted by changes in those libraries, when
the point of Flatpak is that the runtime is API and ABI stable, and all the
rest is under the application's control. Think of every time you saw a mass
change on the fedora-devel list, that's every time your application might break
even though you didn't make a single change to it.
What I'd rather see would be:
- the tools working on source RPMs, rather than binary RPMs, and would generate
flatpak-builder manifests. Those manifests can be then be used in Flathub,
or by the upstream developers in their own repository, or used in the upstream
project's CI to generate nightlies
- Because it has a global view of library usage, and compilation options, Fedora
can make headway on de-duplicating those particular bits for inclusion in the
runtime, or as shared build modules, similar to
https://github.com/flathub/shared-modules
- the Fedora infrastructure can then use those upstream manifests, with little
modification, to build against the Fedora SDK, on Fedora infrastructure, with
Fedora signing keys, so that the chain of trust is not broken, whether with
end-users or contributors
- those upstream maintained Flatpak manifests make it easier to share testing
with upstream, and reduce the duplication of effort in packaging.
- Fedora flatpaks don't require so much handholding when bug fixes are necessary
(with the current infrastructure, it would require to build an RPM package, test,
then generate the Flatpak from it, and test again)
- As an upstream maintainer, I can drop my application's RPM, and consider the
Fedora packaging directly when upstream, making it easier to include as part of the CI
because it wouldn't require much more packaging work to be done.
Hope this makes sense.
Cheers