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 02-07-2010, 08:10 PM
Stelian Ionescu
 
Default Calling unknown commands in an ebuild

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
 
Old 02-07-2010, 09:19 PM
Zac Medico
 
Default Calling unknown commands in an ebuild

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
 
Old 02-07-2010, 11:56 PM
Stelian Ionescu
 
Default Calling unknown commands in an ebuild

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
 
Old 02-08-2010, 12:45 AM
Tomas Touceda
 
Default Calling unknown commands in an ebuild

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
 
Old 02-08-2010, 01:22 AM
Mike Frysinger
 
Default Calling unknown commands in an ebuild

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
 
Old 02-08-2010, 01:24 AM
Mike Frysinger
 
Default Calling unknown commands in an ebuild

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
 
Old 02-08-2010, 06:48 AM
Rmi Cardona
 
Default Calling unknown commands in an ebuild

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,

Rmi
 
Old 02-08-2010, 09:18 AM
Peter Volkov
 
Default Calling unknown commands in an ebuild

В Вск, 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.
 

Thread Tools




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

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