[gentoo-dev] einfo / ewarn banners and die messages

[gentoo-dev] einfo / ewarn banners and die messages

[Ciaran McCreesh]

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

Just a reminder not to do thinks like einfo "********************" in
ebuilds... It's kinda ugly, and it's one of the few 'decided a loooong
time ago' stylistic things which is actually covered in the ebuild doc.

http://bugs.gentoo.org/show_bug.cgi?id=70848 for the tracker bug.

On a similar note, please please please provide a message when using
die, especially if you're doing it in more than one place in a function.
No bug on this, since there're a thousand or more probable candidates
according to glark...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Mike Gardiner]

On Fri, 2004-11-12 at 16:07 +0900, Georgi Georgiev wrote:
> maillog: 11/11/2004-22:02:30(-0800): Tuan Van types
> > And there are ebuilds that do*, in*,  new* without die. The ebuild will 
> > emerged successfully with the missing file(s).
> > Oh, who is glark?
> 
> Shouldn't do*, in*, new* die on a failure?
> 

I would concur, in what situations would we not want a do*, or new* to
not cause a build failure? Shouldn't functions always install something,
and not be used for any sort of 'if something exists, install it, or
else don't bother'?

Mike Gardiner
(Obz)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Tuan Van]

Ciaran McCreesh wrote:

>Just a reminder not to do thinks like einfo "********************" in
>ebuilds... It's kinda ugly, and it's one of the few 'decided a loooong
>time ago' stylistic things which is actually covered in the ebuild doc.
>
>http://bugs.gentoo.org/show_bug.cgi?id=70848 for the tracker bug.
>
>On a similar note, please please please provide a message when using
>die, especially if you're doing it in more than one place in a function.
>No bug on this, since there're a thousand or more probable candidates
>according to glark...
>
>  
>
And there are ebuilds that do*, in*,  new* without die. The ebuild will 
emerged successfully with the missing file(s).
Oh, who is glark?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Georgi Georgiev]

maillog: 11/11/2004-22:02:30(-0800): Tuan Van types
> And there are ebuilds that do*, in*,  new* without die. The ebuild will 
> emerged successfully with the missing file(s).
> Oh, who is glark?

Shouldn't do*, in*, new* die on a failure?

-- 
\    Georgi Georgiev   \  QOTD: "I used to get high on life but        \
 /    chutz@gg3.net     / lately I've built up a resistance."           /
\   +81(90)6266-1163   \                                               \

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Ciaran McCreesh]

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

On Thu, 11 Nov 2004 22:02:30 -0800 Tuan Van <langthang@gentoo.org>
wrote:
| Oh, who is glark?

It's in app-text.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Aaron Walker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Gardiner wrote:
| On Fri, 2004-11-12 at 16:07 +0900, Georgi Georgiev wrote:
|>
|>Shouldn't do*, in*, new* die on a failure?
|>
| I would concur, in what situations would we not want a do*, or new* to
| not cause a build failure? Shouldn't functions always install something,
| and not be used for any sort of 'if something exists, install it, or
| else don't bother'?

Firstly, new* shouldn't need to die since they just cp and call their do*
counterpart, iirc.

Yes, I agree that things should install something or die, not ignore it.
However, IMO, it is considered better style to keep all that kind of stuff in
one place (the ebuild), just like it's usually considered better to handle all
signals and exit code in main() of a C/C++ app.

Cheers
- --
Please keep your hands off the secretary's reproducing equipment.

Aaron Walker < ka0ttic@gentoo.org >	http://dev.gentoo.org/~ka0ttic/
Gentoo/BSD | cron | shell-tools		http://butsugenjitemple.org/~ka0ttic/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFBlKGNC3poscuANHARAsjuAJ98MBLfLmNmHcMIiuH9tAzXqVInLQCg3I71
YBOF3tCzsXUzX5/mjvgUgBk=
=lKYO
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Thomas de Grenier de Latour]

On Fri, 12 Nov 2004 10:11:04 +0800
Mike Gardiner <obz@gentoo.org> wrote:

> in what situations would we not want a do*, or new* to not cause
> a build failure?

In eclasses. I think there are several which make things like
"dodoc README INSTALL COPYRIGHT" without testing if the files
actually exist. But that's easily fixable.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Aron Griffis]

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

Georgi Georgiev wrote:	[Fri Nov 12 2004, 02:07:58AM EST]
> Shouldn't do*, in*, new* die on a failure?

I've flip-flopped on this one.  Previously I said that all dies should
be in the ebuild itself.  I even fixed a lot of ebuilds to call die
after said commands.  But I think that's a losing battle.  Nowadays I
agree that it would be easiest and best if econf, emake, do*, new*,
etc. would die on failure.  The simple reason is that there is no
situation in which one of these commands should fail normally in the
course of an ebuild.

The problem is that it isn't always possible.  Many of the commands
are implemented as scripts in /usr/lib/portage/bin instead of
functions so they can be used on the RHS of xargs.

One possibility would be to implement both: (1) functions in ebuild.sh
that would die automatically and (2) scripts in /usr/lib/portage/bin
that would operate on the RHS of xargs.  You'd lose the ability to die
automatically in the latter case, but hopefully it's rare enough that
it wouldn't be a big deal.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Aron Griffis]

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

Aaron Walker wrote:	[Fri Nov 12 2004, 06:42:06AM EST]
> Firstly, new* shouldn't need to die since they just cp and call their do*
> counterpart, iirc.

except that we'd want to see the correct die message.

> Yes, I agree that things should install something or die, not ignore it.
> However, IMO, it is considered better style to keep all that kind of
> stuff in one place (the ebuild), just like it's usually considered
> better to handle all signals and exit code in main() of a C/C++ app.

I've made the same statement in the past.  You might reconsider that
position in the context of ebuilds.  There is quite a difference:

- In C/C++ it can be expensive to do up-front checking prior to
  calling into an API.  Additionally the exception model of C++ makes
  it natural to do error handling in the caller rather than the
  callee.  After all, how should the callee know what you want to do
  with errors?

- When calling the aforementioned commands in ebuilds, there is never
  a situation when a failure is expected.  If ever a command fails,
  the correct action is to die.  Since that is the case, there is no
  reason to put all the error-handling code in the ebuilds themselves.
  It's just a burden on ebuild writers, and instead the errors often
  get ignored.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Tuan Van]

Georgi Georgiev wrote:

>maillog: 11/11/2004-22:02:30(-0800): Tuan Van types
>  
>
>>And there are ebuilds that do*, in*,  new* without die. The ebuild will 
>>emerged successfully with the missing file(s).
>>Oh, who is glark?
>>    
>>
>
>Shouldn't do*, in*, new* die on a failure?
>
>  
>
I guess you didn't watch close enough while emerging ;) There are 
several times, I saw something such "can not stat foo: no such file or 
directory". Sure, with dodoc or dohtml, missing a COPYING, README don't 
do any harm but missing a startup script, a configure file when you do 
something as:
insinto /etc/foo
newins ${FILESDIR}/bar.conf  bar
when bar.conf doesn't exist (say you forgot to commit it). The ebuild 
will merged without a configure file without anyone notice right away.
Now, go emerge samba-3.0.8 to see for yourself (just something I saw 
recently that I can remember). It will finishes even though there isn't 
a libnss_wins.so in source when you build it without winbind USE flag.
doexe ${S}/source/nsswitch/libnss_wins.so
If we have "doexe ${S}/source/nsswitch/libnss_wins.so || die "doexe 
libnss_wins.so failed", we could have caught that very early.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Mike Gardiner]

> I don't think the absence of some "installables" (ie. the args to doins
> and co.) warrants a fatal error.  Especially if you want the semantics
> of a doins installing "any of the following arguments given to it".  
> 

The "do*" family as documented in the Developer Handbook[1], are defined
as "Installs the specified files/libraries...", and make no mention of
"Installing any...", granted we may be into semantics here.

Someone brought up missing README, COPYING and other documents as an
example of where "do*" should not be required to die. Someone else
brought up the example of a missing file such an initscript, in which
case "do*" should definitely die. On the question of eclasses containing
dodoc's that are 'allowed' to fail, the gnome2 eclass allows derived
ebuilds to set DOCS="foo bar", and will dodoc to all these files. So
each ebuild can specify the docs that are available, and dodoc is never
relied upon to fail. 

We shouldn't be relying on the existence of a file at package time if
we're specifically installing it.

Mike Gardiner
(Obz)





--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Matthew Kenendy]

On Fri, 2004-11-12 at 10:30 -0500, Aron Griffis wrote:
> Aaron Walker wrote:	[Fri Nov 12 2004, 06:42:06AM EST]
> > Firstly, new* shouldn't need to die since they just cp and call their do*
> > counterpart, iirc.
> 
> except that we'd want to see the correct die message.

> - When calling the aforementioned commands in ebuilds, there is never
>   a situation when a failure is expected.  If ever a command fails,
>   the correct action is to die.  Since that is the case, there is no
>   reason to put all the error-handling code in the ebuilds themselves.
>   It's just a burden on ebuild writers, and instead the errors often
>   get ignored.

I don't think the absence of some "installables" (ie. the args to doins
and co.) warrants a fatal error.  Especially if you want the semantics
of a doins installing "any of the following arguments given to it".  

If you really have to, just print out some diagnostic in red.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Matthew Kenendy]

On Sat, 2004-11-13 at 07:07 +0800, Mike Gardiner wrote:
> > I don't think the absence of some "installables" (ie. the args to doins
> > and co.) warrants a fatal error.  Especially if you want the semantics
> > of a doins installing "any of the following arguments given to it".  
> > 
> 
> The "do*" family as documented in the Developer Handbook[1], are defined
> as "Installs the specified files/libraries...", and make no mention of
> "Installing any...", granted we may be into semantics here.

This is all I care about on this topic:  If in src_install I know
src_compile has produced, say, two types of files.  The 1st type end
in .fasl will always be generated and need to be installed.  The second
type end in .dat and will need to be installed if they exist (they might
or might not be generated depending on any number of variables). 

Up until this thread, the solution was simple:

	doins *.fasl *.dat

So what will that need to be if doins calls die because a file '*.dat'
can't be found?

Perhaps doins should take a --strict argument, whose absence will be
compatible with what I do now and whose presence will be appreciated by
those developers forgetting to install init.d run scripts etc.



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Aron Griffis]

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

Matthew Kenendy wrote:	[Sat Nov 13 2004, 06:44:49AM EST]
> Up until this thread, the solution was simple:
> 
> 	doins *.fasl *.dat

Simple but sloppy and error-prone.  What if the *.fasl files are
missing?  You won't know about it until the somebody reports a bug.
Ideally we want to be catching errors before the users, and it would
be easier if the ebuilds didn't allow this kind of sloppiness.

> So what will that need to be if doins calls die because a file '*.dat'
> can't be found?

Good question.  Neither of the following works, but we want something
short:

    [[ -e *.dat ]]      # *.dat doesn't expand (semantics of [[ ]])
    [ -e *.dat ]        # *.dat expands and causes an error

How about this?

    doins *.fasl
    exists *.dat && doins *.dat

In ebuild.sh:

    exists() {
        [[ -e $1 ]]
    }

This works because the glob is expanded before calling exists(), which
then only needs to test the first argument to make a determination.
If the argument is a file expanded from the glob, goodness.  If the
file is the glob itself, it won't be found.

> Perhaps doins should take a --strict argument, whose absence will be
> compatible with what I do now and whose presence will be appreciated by
> those developers forgetting to install init.d run scripts etc.

Same as telling devs to append ||die as we've been saying all along.
Isn't it better to optimize for the common case by dying when files
are missing?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Georgi Georgiev]

maillog: 13/11/2004-05:44:49(-0600): Matthew Kenendy types
> Perhaps doins should take a --strict argument, whose absence will be
> compatible with what I do now and whose presence will be appreciated by
> those developers forgetting to install init.d run scripts etc.

"--strict" v.s. "|| die"

If this is the case, I'd say "|| die" is the more intuitive. Devs who
forget will not appreciate --strict, because it doesn't make much of a
difference if they had to add --strict or append "|| die".

do* et al, should either always die, or be left as they are.

In fact, a "--relaxed" option to those functions makes more sense.

-- 
*>   Georgi Georgiev   *> I have a map of the United States. It's      *>
<*    chutz@gg3.net    <* actual size. I spent last summer folding     <*
*>  +81(90)6266-1163   *> it. People ask me where I live, and I say,   *>
<* ------------------- <* "E6". -- Steven Wright                       <*

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Tom Knight]

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

On Thu, Nov 11, 2004 at 11:45:22PM +0000, Ciaran McCreesh wrote:
> Just a reminder not to do thinks like einfo "********************" in
> ebuilds... It's kinda ugly, and it's one of the few 'decided a loooong
> time ago' stylistic things which is actually covered in the ebuild doc.
> 
> http://bugs.gentoo.org/show_bug.cgi?id=70848 for the tracker bug.
> 

[snip]

I've added a few more of these to the tracker bug. I also came accross a few
e{warn,info} messages that had something like this: *** Warning! ***=20

What's the policy on this? Are they OK or should they be considered the same
as a line of stars or hyphens?


-- 
Tom Knight
tomk@gentoo.org
GPG Public Key: http://dev.gentoo.org/~tomk/tomk.asc

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Ciaran McCreesh]

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

On Sat, 13 Nov 2004 17:12:15 +0000 Tom Knight <tomk@gentoo.org> wrote:
| I've added a few more of these to the tracker bug. I also came accross
| a few e{warn,info} messages that had something like this: *** Warning!
| ***=20
| 
| What's the policy on this? Are they OK or should they be considered
| the same as a line of stars or hyphens?

Personally I think they're pretty excessive... If you feel like going
through and submitting bugs for them, I'd say go for it...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Aron Griffis]

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

Ciaran McCreesh wrote:	[Sun Nov 14 2004, 12:12:38PM EST]
> Personally I think they're pretty excessive... If you feel like
> going through and submitting bugs for them, I'd say go for it...

What's the end goal of these changes?  Some of those markers are
helpful to people.  For example (using echo not einfo... yet)

    ==========================================================
    Building mozilla-firefox-1.0-r2 with the following configuration
        --disable-ldap                  mozilla.org default
        --disable-mailnews              mozilla.org default
    ...

I'm not arguing against your effort, just trying to understand better
what you're accomplishing other than strict compliance to the
handbook.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Ciaran McCreesh]

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

On Sun, 14 Nov 2004 17:41:08 -0500 Aron Griffis <agriffis@gentoo.org>
wrote:
| Ciaran McCreesh wrote:	[Sun Nov 14 2004, 12:12:38PM EST]
| > Personally I think they're pretty excessive... If you feel like
| > going through and submitting bugs for them, I'd say go for it...
| 
| What's the end goal of these changes?

Less junk in my automatic log of einfo and ewarn statements. Stuff using
echo doesn't get picked up, so I personally don't care about that :)

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, Sparc, Mips)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] einfo / ewarn banners and die messages

[Paul de Vrieze]

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

On Saturday 13 November 2004 15:43, Georgi Georgiev wrote:
> maillog: 13/11/2004-05:44:49(-0600): Matthew Kenendy types
>
> > Perhaps doins should take a --strict argument, whose absence will be
> > compatible with what I do now and whose presence will be appreciated
> > by those developers forgetting to install init.d run scripts etc.
>
> "--strict" v.s. "|| die"
>
> If this is the case, I'd say "|| die" is the more intuitive. Devs who
> forget will not appreciate --strict, because it doesn't make much of a
> difference if they had to add --strict or append "|| die".
>
> do* et al, should either always die, or be left as they are.
>
> In fact, a "--relaxed" option to those functions makes more sense.

I agree, even when files might be missing I surely want the packagers to 
know that. I've had some times when a new upstream tarbal did not contain 
a file anymore, while I was still installing it. If the do* functions had 
just died as to be expected, I would have caught the bug. Relying on 
developers never forgetting ||die is not a smart way to handle it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]