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 06-08-2008, 02:48 PM
"Arun Raghavan"
 
Default die/QA notice for do* failure?

Hello All,
We were just discussing if it makes sense to either die or issue a QA
notice if one of the do* functions fail. It turns out that there's
already a bug for this [1]. This potentially applies to all helper
functions that don't currently die on failure.

I think this is a good thing to have (die if one of these functions
fails). Otherwise, every ebuild needs to explicitly chalk out all its
error paths which is cumbersome, and not really required, since a vast
majority of ebuilds *should* fail if one of these functions fails.
Another option is to throw a QA notice (possibly die only
FEATURES="strict").

The bug basically seems only wanting in consensus on this matter,
which is why I'm posting this here.

[1] http://bugs.gentoo.org/show_bug.cgi?id=138792

Cheers,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-08-2008, 02:59 PM
Ciaran McCreesh
 
Default die/QA notice for do* failure?

On Sun, 8 Jun 2008 20:18:23 +0530
"Arun Raghavan" <arunisgod@gmail.com> wrote:
> We were just discussing if it makes sense to either die or issue a QA
> notice if one of the do* functions fail. It turns out that there's
> already a bug for this [1]. This potentially applies to all helper
> functions that don't currently die on failure.

This isn't as simple as you think, since quite a few of these utilities
are called using 'xargs' and so have to be binaries. Whilst Paludis can
deal with external binaries triggering a die because exheres needs it
(exheres has everything as fatal except where preceeded by 'nonfatal'),
I'm not sure that Portage can just now.

Also note that quite a few packages rely upon the current nonfatal
behaviour, so it'd need to be an EAPI bump...

--
Ciaran McCreesh
 
Old 06-08-2008, 03:18 PM
"Arun Raghavan"
 
Default die/QA notice for do* failure?

On Sun, Jun 8, 2008 at 8:29 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
[...]
> This isn't as simple as you think, since quite a few of these utilities
> are called using 'xargs' and so have to be binaries. Whilst Paludis can
> deal with external binaries triggering a die because exheres needs it
> (exheres has everything as fatal except where preceeded by 'nonfatal'),
> I'm not sure that Portage can just now.

I didn't understand you. Even if the external binary can't call die,
what's to prevent the caller from dying based on the return value of
the called binary?

> Also note that quite a few packages rely upon the current nonfatal
> behaviour, so it'd need to be an EAPI bump...

It should not be necessary to define a new EAPI to make sure packages
are not broken. If there really are a lot of packages that rely on the
current behaviour, we can easily implement this in a phased manner:
make it a QA notice to start with and make it default behaviour after
3-6 months or whatever time period is suitable.

BTW, do you have any examples of packages relying on non-fatal
behaviour for do* stuff? It'd be interesting to see why it might be
necessary.

Regards,
--
Arun Raghavan
(http://nemesis.accosted.net)
v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056
e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com
--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-08-2008, 03:27 PM
Ciaran McCreesh
 
Default die/QA notice for do* failure?

On Sun, 8 Jun 2008 20:48:41 +0530
"Arun Raghavan" <arunisgod@gmail.com> wrote:
> On Sun, Jun 8, 2008 at 8:29 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> [...]
> > This isn't as simple as you think, since quite a few of these
> > utilities are called using 'xargs' and so have to be binaries.
> > Whilst Paludis can deal with external binaries triggering a die
> > because exheres needs it (exheres has everything as fatal except
> > where preceeded by 'nonfatal'), I'm not sure that Portage can just
> > now.
>
> I didn't understand you. Even if the external binary can't call die,
> what's to prevent the caller from dying based on the return value of
> the called binary?

Then we're back to having people do dobin || die, which is precisely
what we're trying to solve.

> > Also note that quite a few packages rely upon the current nonfatal
> > behaviour, so it'd need to be an EAPI bump...
>
> It should not be necessary to define a new EAPI to make sure packages
> are not broken.

Yes it should. It's a change in behaviour in functionality upon which
quite a lot of things depend.

> If there really are a lot of packages that rely on the
> current behaviour, we can easily implement this in a phased manner:
> make it a QA notice to start with and make it default behaviour after
> 3-6 months or whatever time period is suitable.

EAPIs *are* the phased manner.

> BTW, do you have any examples of packages relying on non-fatal
> behaviour for do* stuff? It'd be interesting to see why it might be
> necessary.

Various things do dodoc AUTHORS README BLAH BLAH, even when some of
them don't exist. And more do it via eclass variables like DOCS.

--
Ciaran McCreesh
 

Thread Tools




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

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