FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-12-2012, 08:36 PM
Brian Harring
 
Default EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

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
 
Old 09-13-2012, 03:30 AM
Ben de Groot
 
Default EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

On 13 September 2012 04:36, Brian Harring <ferringb@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
 
Old 09-13-2012, 05:48 AM
Ulrich Mueller
 
Default 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
 
Old 09-13-2012, 05:53 AM
Mike Frysinger
 
Default 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
 
Old 09-13-2012, 05:54 AM
Mike Frysinger
 
Default 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
 
Old 09-13-2012, 06:22 AM
Ulrich Mueller
 
Default 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
 
Old 09-13-2012, 06:29 AM
Mike Frysinger
 
Default 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
 
Old 09-13-2012, 08:15 AM
David Leverton
 
Default EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

On 13 September 2012 06:48, Ulrich Mueller <ulm@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*
 
Old 09-13-2012, 08:32 AM
Ulrich Mueller
 
Default 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
 
Old 09-13-2012, 09:15 AM
Brian Harring
 
Default 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
 

Thread Tools




All times are GMT. The time now is 07:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org