On Wed, Jul 19, 2017 at 5:17 AM, Jiří Eischmann <eischmann@xxxxxxxxxx> 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@xxxxxxxxx> >> wrote: >> > 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 work". _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
