On Thu, 2017-07-20 at 11:13 -0700, Japheth Cleaver wrote:
On 7/19/2017 8:05 AM, Owen Taylor wrote:
> On Wed, 2017-07-19 at 12:56 +0200, Dominik 'Rathann' Mierzejewski
> > [...]
> 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
> And some of that is going to be in how we generate Flatpaks from Fedora
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"?
The main point I'll make here is that the thread is discussing my change
proposal to generate flatpaks out of Fedora content, and so the main
question is whether those flatpaks are going to handle bundled dependencies
in a sane way. Not about all possible flatpaks.
(Note that the ability to install third party flatpaks is not listed as
a benefit of my change proposal... and we already have that in F25/F26
in any case.)
Of course, one could do that in an RPM too, but then it would be
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.
While there are strong barriers in place to make sure that the RPMs that
are *part* of Fedora are high quality, we don't have any barriers in place
to make sure that an RPM a user installs from a third party is high quality -
if a users install the Google Chrome, or Adobe Flash, or Skype, or whatever RPM
it probably doesn't meet your requirements for a high-quality RPM.
It's not really any different with Flatpaks, other than that we have some
extra protections that aren't there with RPMs:
- A flatpak can't make arbitrary modifications to your system at
- libraries installed in a flatpak cannot affect any other application
- flatpaks are potentially sandboxed at runtime
- The source repository when you install a flatpak only is used to
update that flatpak and does not participate in general package
So the potential damage from a bad flatpak is more limited.