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 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. Regards, Owen _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
