On Wednesday, 19 July 2017 at 17:05, Owen Taylor wrote:
On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann'
> 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
> 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
* 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
And some of that is going to be in how we generate Flatpaks from Fedora
* 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
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.
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"