Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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
overkill.
not sure how your --save/--restore isn't a --push/--pop already
--save/--restore would keep one saved state (which would be
overwritten with the next --save), whereas --push/--pop would maintain
a stack.
Ulrich
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 allow for nested calls, but maybe that would be
overkill.
not sure how your --save/--restore isn't a --push/--pop already
--save/--restore would keep one saved state (which would be
overwritten with the next --save), whereas --push/--pop would maintain
a stack.
that wouldn't really be any different than if you implement the -r
option like so:
- `addwrite /foo` would always append the path regardless of
existence already in the variable
- `addwrite -r /foo` would remove exactly 1 occurence
so if you don't want to do push/pop, let's stick with just adding a -r
flag and implementing things as described above as it makes dev's
lives simpler.
-mike
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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] pathway # for example, to do a removal.
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 IMHO - having to do it
manually seems a little error-prone.
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
To start the bikeshedding: For some reason I associate less (the
pager) in a sandbox with this. ;-) Maybe nosandbox or sandboxoff?
sansbox? *flees*
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 IMHO - having to do it
manually seems a little error-prone.
Maybe we should just document the SANDBOX_* variables? Looks like the
easiest solution to me.
The problem with adding an option to addwrite is that eclasses would
have to stick with the existing solution, or add a pointless case
distinction. Otherwise it won't work for all EAPIs.
Ulrich
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 [[ ${___ECLASS_ONCE_LIBTOOL} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_LIBTOOL=recur -_+^+_- spank
Converting that is easy enough, and I'll be doing that work for
gentoo-x86 if folks don't have an issue.
pick a funner prefix and i approve
_LIBTOOL_ECLASS_GOT_SPANKED_ALREADY
Either that or one could just inject futurama quotes:
_LIBTOOL_ECLASS_DOESNT_WANT_TO_LIVE_ON_THIS_PLANET_ANYMORE
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
fine idea
withoutsandbox. ;)
Joke aside, 'nosandbox' is more consistent; also, there's basically
one usage in the tree (virtualx) that would need it, although the
level of ebuild usage for that, I do not know- donnie might, that was
his code originally iirc.
~harring
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 world
to lose this, but it would be a bit of a shame IMHO - having to do it
manually seems a little error-prone.
Maybe we should just document the SANDBOX_* variables? Looks like the
easiest solution to me.
The problem with adding an option to addwrite is that eclasses would
have to stick with the existing solution, or add a pointless case
distinction. Otherwise it won't work for all EAPIs.
well, if you want to focus on the $now, then you're mostly correct.
however, as we've done in the past, it's generally pretty easy to
implement functionality in say eutils.eclass so that other places
don't have to worry about different EAPI code paths. then in the
$future, there is only the code provided by EAPI.
-mike
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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), leading to breakage.
Thus a proposal for EAPI5 has been made, banning ebuilds/eclasses from
using/accessing __, and requiring the PM to store it's internals in
that namespace.
Basically, instead of portage doing thus:
is_function dyn_pkg_preinst dyn_pkg_preinst
It does thus:
__is_function __dyn_pkg_preinst __dyn_pkg_preinst.
Aside from avoiding accidental conflicts/usage, the standardized
namespacing makes it a helluva lot easier to have repoman/qa tools
look for bad usage.
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 -_+^+_- spank
Converting that is easy enough, and I'll be doing that work for
gentoo-x86 if folks don't have an issue.
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 via extending the
sandbox functions a bit:
addwrite [-r|--remove] pathway # for example, to do a removal.
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
which is just
sandboxless() {
SANDBOX_ON=0 $@
}
or SYDBOX_ON=0 (or their equivalent var) for sydbox usage.
Comments?
~harring
I support this. It seems very sane.
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 via extending the
sandbox functions a bit:
addwrite [-r|--remove] pathway # for example, to do a removal.
As already discussed on IRC, a -r option may have undesired effects.
For example:
addwrite /foo/bar
# some commands writing to /foo/bar here
addwrite -r /foo/bar # try to restore previous state
Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it.
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
overkill.
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
To start the bikeshedding: For some reason I associate less (the
pager) in a sandbox with this. ;-) Maybe nosandbox or sandboxoff?
Ulrich
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 -_+^+_- spank
Converting that is easy enough, and I'll be doing that work for
gentoo-x86 if folks don't have an issue.
pick a funner prefix and i approve
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
fine idea
-mike
Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __
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 grey
zone; regardless, we can actually address that via extending the
sandbox functions a bit:
addwrite [-r|--remove] pathway # for example, to do a removal.
As already discussed on IRC, a -r option may have undesired effects.
For example:
addwrite /foo/bar
# some commands writing to /foo/bar here
addwrite -r /foo/bar # try to restore previous state
Now if /foo/bar was in SANDBOX_WRITE before, it's now removed from it.
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
overkill.
not sure how your --save/--restore isn't a --push/--pop already
For instances where the sandbox needs to be turned off for a command-
we do the same thing we did w/ nonfatal;
sandboxless the command and args
To start the bikeshedding: For some reason I associate less (the
pager) in a sandbox with this. ;-) Maybe nosandbox or sandboxoff?
sandboxoff
-mike
