On Wed, Jul 19, 2017 at 5:17 AM, Jiří Eischmann <eischmann(a)redhat.com> wrote:
Nico Kadel-Garcia píše v Út 18. 07. 2017 v 22:44 -0400:
> On Fri, Jul 14, 2017 at 12:59 PM, Debarshi Ray <rishi.is(a)lostca.se>
> > On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
> > > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > > > F29: packagers (of graphical applications) must create
> > > > Flatpaks of
> > > > their applications if possible. They *may* keep standard
> > > > RPM
> > > > packaging.
> > >
> > > At least we see where this is going.
> > >
> > > If RPMs of the graphical application work fine now, what on earth
> > > is
> > > the point of forcing packagers to make Flatpaks? Sandboxing
> > > isn't one
> > > of them - as already explained, sandboxing is orthogonal to
> > > packaging.
> > Huh? How would you get sandboxing without Flatpaks? Unless you are
> > proposing a different sandboxing technology.
> By putting them in "/opt", the way other sanely packaged 3rd party
> components do?
How does that ensure any sandboxing?
Complete sandboxing, with isolation from the network stack and the
rest of the host's filesystem? It doesn't. But functional sandboxing,
where a full software suite with its own libraries and binaries to be
supported separately from the rest of the operating sytem, Yeah, it
works pretty well to set up a separate workspace there and wrap the
calls of that customized suite in an "enable" script or a shell
wrapper, much as the Software Collections for RHEL have been doing
functionally for years for software backported from Fedora testing.
Even a chroot cage can be run there for service isolation from the
rest of the system. Gnome packaging... well, that's considerably
harder because it spews into $HOME/.gnome, in manners inconsistent
between even minor releases. Packaging Gnome looks like a fabulous
idea at first glance. It's one of those situations where the "first
90% takes 90% of the work, and the last 10% takes the next 300% of the