Gentoo Archives: gentoo-dev

From: Ulrich Mueller <ulm@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
Date: Thu, 13 Sep 2012 05:49:39
Message-Id: 20561.29622.649540.849023@a1i15.kph.uni-mainz.de
In Reply to: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __ by Brian Harring
1 >>>>> On Thu, 13 Sep 2012, Brian Harring wrote:
2
3 > Note there is a few vars we need to exempt; that list is currently
4 > SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule.
5 >
6 > For SANDBOX_*, while that's a PM internal, that's a bit of a grey
7 > zone; regardless, we can actually address that via extending the
8 > sandbox functions a bit:
9 >
10 > addwrite [-r|--remove] pathway # for example, to do a removal.
11
12 As already discussed on IRC, a -r option may have undesired effects.
13 For example:
14
15 addwrite /foo/bar
16 # some commands writing to /foo/bar here
17 addwrite -r /foo/bar # try to restore previous state
18
19 Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it.
20
21 Maybe it's better to add a --{save,restore} option pair:
22
23 addwrite --save /foo/bar
24 # some commands writing to /foo/bar here
25 addwrite --restore # restore last saved state
26
27 or --{push,pop} to allow for nested calls, but maybe that would be
28 overkill.
29
30 > For instances where the sandbox needs to be turned off for a command-
31 > we do the same thing we did w/ nonfatal;
32 >
33 > sandboxless <the command and args>
34
35 To start the bikeshedding: For some reason I associate "less (the
36 pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"?
37
38 Ulrich

Replies