----- 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 _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
