On Wednesday, 19 July 2017 at 17:05, Owen Taylor wrote: > On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann' Mierzejewski > wrote: > > On Tuesday, 18 July 2017 at 20:43, Owen Taylor wrote: > > [...] > > > An example of where conditionals may be useful is when a library is > > > bundled into a Flatpak - the rebuild for the flatpak could skip > > > building the developer docs because they have complicated build > > > dependencies (graphviz or whatever.) We'll have to see how frequent > > > that is as we work through real examples. > > > > The bundling thing is what I'm afraid of. If we don't make it a > > requirement or at least a strong recommendation to unbundle libraries > > from Flatpaks, then we'll end up with Android app store-like > > ecosystem, where everyone bundles everything which is not in one of > > the > > runtimes and even runtimes duplicate libraries between each other, > > because it's easy and not forbidden. And since there's no easy way > > to track bundled stuff inside Flatpaks, we're much worse off than > > where we are with RPM packages currently. > > Bundling enables some of the key features of Flatpak - the ability to > try out new versions of an application even if they require library > versions newer than what you have on your system, the ability to have a > single binary package that can be installed on different Linux > distributions, the assurance that installing an application will never > prevent you from upgrading your operating system due to missing > dependencies, and so forth. > > And yes, there are downsides from bundling. But we're trying to address > those downsides as much as possible. Some of that is in the Flatpak > system: > > * Runtimes mean that common libraries (libc, X11, etc) and libraries > that often have security updates (image libraries, crypto libraries) > will not be bundled. > * The use of ostree for storage means that if the exact same file is > bundled in two separate Flatpaks, it will be only stored on disk and in > memory once. > > And some of that is going to be in how we generate Flatpaks from Fedora > content: > > * Bundled libraries will not be arbitrary source code builds, they will > be built from the exact same spec files in dist-git. > * We will track (via the PDC) what versions of what packages are
What's "PDC"? > included in every Flatpak runtime and app we ship, and can > automatically rebuild and update the runtime and apps as needed. > * We will include a manifest of the component RPM versions in each > Flatpak runtime and app. > > There are definitely some open questions, and we'll have to pay close > attention to how much duplication we are getting in practice, and look > at whether we need to adjust the composition of the Fedora runtime and > our build methods to reduce duplication, but it's definitely not going > to be a Wild West where every application you install on your system > has its own copy of libz that was downloaded somewhere off the > internet. That is excellent. I wish this had been mentioned either on the change proposal page or early in this thread. Thank you for having thought this through. If that's the plan, then it should have much less opposition then you see in this thread. I still think that this proposal makes more sense for Atomic Workstation than for a traditional RPM-based Fedora product due to duplication between Flatpak runtime(s) and installed packages. Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
