[gentoo-dev] Calling unknown commands in an ebuild

[gentoo-dev] Calling unknown commands in an ebuild

[Stelian Ionescu]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
I've seen cases of ebuilds calling epatch without inheriting from eutils
which compiled and installed (apparently) fine but possibly broken
binaries. Examples of cases where "set -e" would have helped: 303849,
297063, 260279, 221257,
https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
and perhaps others I haven't managed to find in bugzilla

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Zac Medico]

On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
> Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> I've seen cases of ebuilds calling epatch without inheriting from eutils
> which compiled and installed (apparently) fine but possibly broken
> binaries. Examples of cases where "set -e" would have helped: 303849,
> 297063, 260279, 221257,
> https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
> and perhaps others I haven't managed to find in bugzilla

I don't know what kind of side-effects set -e would introduce, but
we can easily add a repoman check for epatch calls without eutils
inherit.

Portage already does a search of the build log for 'command not
found' messages and generates a QA warnings. Set
PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa" in /etc/make.conf
if you want to have those warnings logged.
-- 
Thanks,
Zac

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Stelian Ionescu]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

On Sun, 2010-02-07 at 14:19 -0800, Zac Medico wrote:
> On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
> > Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> > I've seen cases of ebuilds calling epatch without inheriting from eutils
> > which compiled and installed (apparently) fine but possibly broken
> > binaries. Examples of cases where "set -e" would have helped: 303849,
> > 297063, 260279, 221257,
> > https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
> > and perhaps others I haven't managed to find in bugzilla
> 
> I don't know what kind of side-effects set -e would introduce, but
> we can easily add a repoman check for epatch calls without eutils
> inherit.

"Exit immediately if a pipeline (which may consist of a single simple
command), a subshell command enclosed in parentheses, or one of the
commands executed as part of a command list enclosed by braces (see
SHELL GRAMMAR above) exits with a non-zero status.  The shell does not
exit if the com- mand that fails is part of the command list
immediately following a while or until keyword, part of the test
following the if or elif reserved words, part of any command executed
in a && or || list except the command following the final && or ||,
any command in a pipeline but the last, or if the command's return
value is being inverted with !.  A trap on ERR, if set, is executed
before the shell exits.  This option applies to the shell environment
and each subshell environment separately (see COMMAND EXECUTION
ENVIRONMENT above), and may cause subshells to exit before executing
all the commands in the subshell."

> Portage already does a search of the build log for 'command not
> found' messages and generates a QA warnings. Set
> PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa" in /etc/make.conf
> if you want to have those warnings logged.

My point is that whenever the ebuild is trying to execute a command that
does not exist, it should die immediately because there's no way to know
how the failure to execute that command might affect the rest of the
build process
epatch was just an example because it's probably the most used function
from eutils.eclass

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Tomas Touceda]

El 07/02/2010, a las 18:19, Zac Medico <zmedico@gentoo.org> escribió:

> On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
>> Wouldn't it be a good idea to use "set -e" in the ebuild  
>> environment ?
>> I've seen cases of ebuilds calling epatch without inheriting from  
>> eutils
>> which compiled and installed (apparently) fine but possibly broken
>> binaries. Examples of cases where "set -e" would have helped: 303849,
>> 297063, 260279, 221257,
>> https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
>> and perhaps others I haven't managed to find in bugzilla
>
> I don't know what kind of side-effects set -e would introduce, but
> we can easily add a repoman check for epatch calls without eutils
> inherit.
>
> Portage already does a search of the build log for 'command not
> found' messages and generates a QA warnings. Set
> PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa" in /etc/make.conf
> if you want to have those warnings logged.

But, shouldn't it die when a command isn't found? Not only with epatch.

> -- 
> Thanks,
> Zac
>

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1191 bytes --]

On Sunday 07 February 2010 16:10:10 Stelian Ionescu wrote:
> Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> I've seen cases of ebuilds calling epatch without inheriting from eutils
> which compiled and installed (apparently) fine but possibly broken
> binaries.

this is not the way to approach the problem.  'set -e' has a lot of 
implications people don't realize.  _any_ command that exits with non-zero 
will break things.  such as:
	matches=`grep foo ./some-file`
no matches of 'foo' will cause the ebuild to exit immediately.  it doesnt take 
much effort to find plenty of other examples.

it also valid to try and do something like `foo --version >& /dev/null` as a 
naive test to see if a program exists and works.  messing with the fundamental 
'command not found' behavior may unintentionally break this.

> https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
> and perhaps others I haven't managed to find in bugzilla

many of those would still fail with `set -e` in the ebuild environment because 
the missing command is run through a build system like makefiles.
	ebuild -> make -> shell -> no command found
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1093 bytes --]

On Sunday 07 February 2010 17:19:43 Zac Medico wrote:
> On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
> > Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> > I've seen cases of ebuilds calling epatch without inheriting from eutils
> > which compiled and installed (apparently) fine but possibly broken
> > binaries. Examples of cases where "set -e" would have helped: 303849,
> > 297063, 260279, 221257,
> > https://bugs.gentoo.org/buglist.cgi?quicksearch=command+not+found
> > and perhaps others I haven't managed to find in bugzilla
> 
> I don't know what kind of side-effects set -e would introduce, but
> we can easily add a repoman check for epatch calls without eutils
> inherit.

if we wanted to specifically target semi-common errors (and i think 'epatch' 
w/out eutils.eclass falls into this category), then a repoman check would be 
good.

it might also be useful to add a default epatch() to the initial env that 
would be clobbered when the inherit occurred.
	epatch() { die "you need to inherit eutils.eclass to use epatch" ; }
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Rémi Cardona]

Le 08/02/2010 03:24, Mike Frysinger a écrit :
> if we wanted to specifically target semi-common errors (and i think 'epatch' 
> w/out eutils.eclass falls into this category), then a repoman check would be 
> good.
> 
> it might also be useful to add a default epatch() to the initial env that 
> would be clobbered when the inherit occurred.
> 	epatch() { die "you need to inherit eutils.eclass to use epatch" ; }

+1, that's a very good idea! I've stopped counting how many times that's
happened to me.

I'm sure there are other common mistakes we all do, but this particular
one is a low-hanging fruit.

Cheers,

Rémi

Re: [gentoo-dev] Calling unknown commands in an ebuild

[Peter Volkov]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

В Вск, 07/02/2010 в 21:24 -0500, Mike Frysinger пишет:
> it might also be useful to add a default epatch() to the initial env that 
> would be clobbered when the inherit occurred.
> 	epatch() { die "you need to inherit eutils.eclass to use epatch" ; }

After fixing breakage that was introduced by dropping inherit eutils
from distutils.eclass I think we must have such thing. But one function
just covers most common case while we need to cover all cases. What
about pregenerating env file with script like in attachment?

$ awk -f generate-die-eclass-env /usr/portage/eclass/*.eclass

I guess it's possible to generate such env file on server side and make
portage use it if file exists... Opinions?

-- 
Peter.

[-- Attachment #2: generate-die-eclass-env --]
[-- Type: application/x-awk, Size: 338 bytes --]