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 practice! Owen ----- Original Message ----- > On 07/06/2017 11:05 AM, Jaroslav Reznik wrote: > > > > = System Wide Change: Graphical Applications as Flatpaks = > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks > Change owner(s): > * Owen Taylor <otaylor@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
