Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Calling unknown commands in an ebuild (http://www.linux-archive.org/gentoo-development/322203-calling-unknown-commands-ebuild.html)

Stelian Ionescu 02-07-2010 08:10 PM

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

Zac Medico 02-07-2010 09:19 PM

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

Stelian Ionescu 02-07-2010 11:56 PM

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

Tomas Touceda 02-08-2010 12:45 AM

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

Mike Frysinger 02-08-2010 01:22 AM

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

Mike Frysinger 02-08-2010 01:24 AM

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

Rmi Cardona 02-08-2010 06:48 AM

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

Peter Volkov 02-08-2010 09:18 AM

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.


All times are GMT. The time now is 09:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.