Re: Call for participation: Fedora Flatpaks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux