Thanks for the thoughtful comment!
The ability for different applications to bundle different library versions is only one of
the benefits that Flatpak's bring - other benefits like sandboxing, the ability to try
out applications from newer and older versions of Fedora, and the ability to do robust
upgrades without disturbing running applications would apply even if Fedora was keeping
the idea of a single big package set.
And some of my early attempts to figure out Flaptak building actually assumed the big
consistent package set.
But because Fedora is moving toward a modular world, the current plan for Flatpak support
tries to work within that framework rather than the older big-package-set idea. And in
that world, as long as the libpng maintainer is maintaining a libpng-1.6 branch in
dist-git, you'll be able to use that for your application even if other applications
have moved to libpng-1.8.
[ Hypthetical example, libpng should be in the runtime, not bundled with the app, because
it is security critical. But the same applies to most easy examples. ]
But it should also be noted that modularity does not in any way abandon the idea of the
collective maintenance of packages. There is still a single dist-git repository for each
library or application, even if it is built into multiple different modules. And those
dist-git repositories have to have clear lifetimes and interrelationships - a maintained
branch of libpng can't depend on a branch of libz that is no longer maintained.
In some places (for example, security updates) I don't think we've fully figured
out all the implications of this move to dist-git as the center of information, but
we'll have to make it work for modularity to work.
One thing that the Flatpak work does is give some good concrete examples of modularity in
----- Original Message -----
> On 07/06/2017 11:05 AM, Jaroslav Reznik wrote:
> = System Wide Change: Graphical Applications as Flatpaks =
> Change owner(s):
> * Owen Taylor <otaylor(a)redhat.com> This change is to enable package
> maintainers to build Flatpaks of
> their applications and make those Flatpaks available for installation.
> I do recognize that the containerization trend solves enough problems to be
> an attractive and perhaps inevitable development. My concern is more from
> the Fedora governance side: given that Fedora is historically a coherent
> RPM-based distribution, the containerization has an opportunity cost, in at
> least two ways:
> - it could distract already overworked package maintainers from properly
> coordinating ("I don't have time to deal with those dependencies, I will
> just wrap the stuff I need into a flatpack and have a beer and a movie")
> - it could distract users from demanding a well-put-together base ("I don't
> have time to chase and report this bug; I will just install that flatpack").
> I do appreciate that if there are technical solutions to the downsides of
> containerization (security lifecycle, combinatorial divergence, etc.), it
> may end up replacing the package-based distribution model, but I think it's
> too early to declare such change. So, from the point of view of Fedora's
> available resources, are the benefits to Fedora compelling enough to justify
> this project?
> Please note that I am not arguing against this idea, just pointing out that
> the Fedora community should think through its broader consequences.
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org