On Wed, Jan 17, 2018 at 1:33 PM, Mike Frysinger <vap...@gentoo.org> wrote:

> On 16 Jan 2018 23:32, Mike Gilbert wrote:
> > On Tue, Jan 16, 2018 at 4:46 PM, Mike Frysinger wrote:
> > > Some ebuilds are a bit hard to fix their use of the network in src
> > > phases, so allow them to disable things.  This allows us to turn off
> > > access by default and for the vast majority while we work out how to
> > > fix the few broken packages.
> >
> > If we are going to allow network sandboxing to be disabled in
> > individual ebuilds, we should also allow the other sandboxes to be
> > disabled for the same reasons. sys-apps/sandbox has been notoriously
> > buggy, for example.
>
> that sandbox can already be disabled dynamically in ebuilds as needed.
> i don't really see a reason for it to be a RESTRICT value.
>

It used to be in RESTRICT even; it was dropped in 2015.

https://archives.gentoo.org/gentoo-pms/message/05f8faf4f1477b4406619b92bb7722b7

I don't mind if portage acts on other tokens (allowed in the spec). I do
think we should file a patch to PMS.
If they accept it, other PMs can implement this feature in a future EAPI
(and in portage, it will just work in all EAPIs)

But if we never tell them about the tokens, they can never implement them.

-A

-mike
>

Reply via email to