On Thu, 13 Sep 2012, Mike Frysinger wrote:
Maybe it's better to add a --{save,restore} option pair:
addwrite --save /foo/bar
# some commands writing to /foo/bar here
addwrite --restore # restore last saved state
or --{push,pop} to allow for nested calls, but maybe that would be
On Thu, Sep 13, 2012 at 2:22 AM, Ulrich Mueller wrote:
On Thu, 13 Sep 2012, Mike Frysinger wrote:
Maybe it's better to add a --{save,restore} option pair:
addwrite --save /foo/bar
# some commands writing to /foo/bar here
addwrite --restore # restore last saved state
or --{push,pop} to
On 13 September 2012 06:48, Ulrich Mueller u...@gentoo.org wrote:
On Thu, 13 Sep 2012, Brian Harring wrote:
For SANDBOX_*, while that's a PM internal, that's a bit of a grey
zone; regardless, we can actually address that via extending the
sandbox functions a bit:
addwrite [-r|--remove]
On Thu, 13 Sep 2012, David Leverton wrote:
It's nice to be able to do
local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits. It's not the end of the world
to lose this, but it would be a bit of a shame
On Thu, Sep 13, 2012 at 01:53:21AM -0400, Mike Frysinger wrote:
On Wed, Sep 12, 2012 at 4:36 PM, Brian Harring wrote:
Currently, there is a minor amount of ebuild/eclass usage of things
named __*; ~90% of it is 'import once' eclass code like the following:
if [[
On Thu, Sep 13, 2012 at 4:32 AM, Ulrich Mueller wrote:
On Thu, 13 Sep 2012, David Leverton wrote:
It's nice to be able to do
local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits. It's not the end of the
On 13 September 2012 04:36, Brian Harring ferri...@gmail.com wrote:
Hola folks.
Currently portage exposes a fair amount of it's internal
implementation via vars/funcs into the ebulid env; this frankly makes
it easier for ebuilds/eclasses to localize themselves to portage
(rather than PMS),
On Thu, 13 Sep 2012, Brian Harring wrote:
Note there is a few vars we need to exempt; that list is currently
SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule.
For SANDBOX_*, while that's a PM internal, that's a bit of a grey
zone; regardless, we can actually address that
On Wed, Sep 12, 2012 at 4:36 PM, Brian Harring wrote:
Currently, there is a minor amount of ebuild/eclass usage of things
named __*; ~90% of it is 'import once' eclass code like the following:
if [[ ${___ECLASS_ONCE_LIBTOOL} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_LIBTOOL=recur
On Thu, Sep 13, 2012 at 1:48 AM, Ulrich Mueller wrote:
On Thu, 13 Sep 2012, Brian Harring wrote:
Note there is a few vars we need to exempt; that list is currently
SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule.
For SANDBOX_*, while that's a PM internal, that's a bit of a
10 matches
Mail list logo
