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 > > wrote: > > > [...] > > 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: > > [...] > > And some of that is going to be in how we generate Flatpaks from Fedora > > content: > > [...] > > > 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 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. 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 install time. - 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 resolution. So the potential damage from a bad flatpak is more limited. Owen _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
