I'd like to invite Fedora contributors to start creating Flatpaks of graphical applications in Fedora. We're still working on putting the final pieces into place to have a complete story from end to end, but it's definitely close enough to get started.
If you maintain a graphical application, please try creating a Flatpak of it. Your experience will vary - some applications are quite easy, but if your application, for example:
* Uses qt5-qtwebengine * Uses many KDE libraries * Uses many Perl or Python packages * Uses texlive
etc, then you may want to wait - we will eventually be creating shared builds to make bundling these easier. Also, if your application has a system service, installs a polkit policy, or otherwise is not self-contained, then it's not a good candidate for a Flatpak.
Or you can pick one of 280+ applications that have been identfied as easy to Flatpak:
https://fedoraproject.org/wiki/Flatpak:Easy
and assist out the application package maintainer by creating a Flatpak of that.
An introduction, draft tutorial and other documentation can be found at:
https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/
(The plan is to integrate this into docs.fedoraproject.org. For now, the documentation source is at: https://github.com/owtaylor/fedora-docs-flatpak)
For help, please ask on #fedora-workstation on Freenode, or mail desktop@lists.fedoraproject.org.
Owen
Hey Owen,
----- Original Message -----
I'd like to invite Fedora contributors to start creating Flatpaks of graphical applications in Fedora. We're still working on putting the final pieces into place to have a complete story from end to end, but it's definitely close enough to get started.
As discussed earlier in both mailing-lists and face-to-face, I'd like to know why this is interesting for either upstream or downstream developers.
Who is the target for this feature, why does it make sense for packagers to package within Fedora (or eventually CentOS, or RHEL), rather than upstream, whether in Flathub or an independent repository?
I can expand on what I think are the benefits for Fedora, and its downstreams, but that would require making guesses at roadmaps that I don't have a view into.
Cheers
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:
* 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. * 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 * Benefit to Fedora users: they can get Flatpaks and runtimes from a source they already have trust in. * 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.) * 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. * Benefit to Fedora contributors: they can make their packaging work available across distributions and distribution versions. * 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.
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.
Regards, Owen
On Fri, Sep 7, 2018 at 10:44 AM, Bastien Nocera bnocera@redhat.com wrote:
Hey Owen,
----- Original Message -----
I'd like to invite Fedora contributors to start creating Flatpaks of graphical applications in Fedora. We're still working on putting the
final
pieces into place to have a complete story from end to end, but it's definitely close enough to get started.
As discussed earlier in both mailing-lists and face-to-face, I'd like to know why this is interesting for either upstream or downstream developers.
Who is the target for this feature, why does it make sense for packagers to package within Fedora (or eventually CentOS, or RHEL), rather than upstream, whether in Flathub or an independent repository?
I can expand on what I think are the benefits for Fedora, and its downstreams, but that would require making guesses at roadmaps that I don't have a view into.
Cheers _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org 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@ lists.fedoraproject.org
----- 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
Urgh, unfinished trains of thought.
----- Original Message -----
- 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
...on getting that same application into end-users hands. What do you think would happen to the opt-in creation of Fedora Flatpaks if you get none of the benefits of being able to empower upstream with maintaining that package?
- 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
That doesn't seem to require the Flatpaks to be build from binary RPMs, or RPMs at all. The Fedora/RHEL runtime is part of the OS, so no duplication of work, but packaging application-supporting libraries would be.
desktop@lists.fedoraproject.org