On 7/19/2017 8:05 AM, 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
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.
Isn't one of the selling points for this, however, the use of Flatpacks
written/produced by generic third party app vendors to publish without
specially constructed packages by Fedora participants? If that's the
case, what's to say that any upstream Flatpack/container/image will have
the same care of using runtime definitions or expectations as the ones
curated by the Workstation WG (or Freedesktop group, or whomever)? Why
couldn't a third-party app creator bundle libz on a regular basis
"because it's easier"?
Of course, one could do that in an RPM too, but then it would be berated
as a "badly constructed RPM". It seems like one of the point of
Flatpacks is to reach out to app developers who can't be bothered to
write a decent .spec file but whose apps we still want to have easily
installable by Fedora users.
Multiple versions of apps installed in parallel aside, how does this not
end us back up in the same place?
-jc
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
