Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux