Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Vaeth]

Steve Long wrote:

> Thomas Sachau wrote: [...]
>
> > [[ -n ${DOCS} ]] && dodoc ${DOCS}
[...]
> 
> It might be wise to use an array for DOCS there

Since I have now seen suggestions for using arrays unnecessarily
at least twice (see also
  [RFC] Ability to pass arguments to src_configure/src_compile
but I am only speaking about the usage of _arrays_ here),
let me remark that the more clever way to this is

  [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"

This way, people can simply quote as they like:

DOCS="'filename with spaces' filename_without_space doc/*"

or also

DOCS="just_one_filename_without_special_characters"

or also - when Push from /usr/bin/functions-eix.sh is used
(which might be implemented simpler without using other functions):

Push DOCS 'filename with spaces' filename_without_space "${S}"/doc/*


Not only has this the advantage that it is POSIX (and thus does not
force ebuilds to use the particular shell "bash" - a policy which perhaps
some day might be changed: It is dangerous to depend on a particular
implementation), the array-less solution is also much simpler to
implement, easy to understand from the source, and clearer in usage.
Case distinctions like

> isArr() [[ $(declare -p "$1" 2>/dev/null) = 'declare -a'* ]]
> if isArr DOCS; then
>    ((${#DOCS[@]})) && dodoc "${DOCS[@]}"
> else [[ $DOCS ]] && dodoc $DOCS
> fi

are just awful.

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Thomas Anderson]

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

On Sun, Sep 21, 2008 at 08:18:05AM +0200, Vaeth wrote:
> Steve Long wrote:
> 
> > Thomas Sachau wrote: [...]
> >
> > > [[ -n ${DOCS} ]] && dodoc ${DOCS}
> [...]
> > 
> > It might be wise to use an array for DOCS there
> 
> Since I have now seen suggestions for using arrays unnecessarily
> at least twice (see also
>   [RFC] Ability to pass arguments to src_configure/src_compile
> but I am only speaking about the usage of _arrays_ here),

Er, how were arrays use unnecessarily in the src_configure/src_compile
case?

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

[gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Vaeth wrote:

> Steve Long wrote:
> 
>> Thomas Sachau wrote: [...]
>>
>> > [[ -n ${DOCS} ]] && dodoc ${DOCS}
> [...]
>> 
>> It might be wise to use an array for DOCS there
> 
> Since I have now seen suggestions for using arrays unnecessarily
> at least twice (see also
>   [RFC] Ability to pass arguments to src_configure/src_compile
> but I am only speaking about the usage of _arrays_ here),
> let me remark that the more clever way to this is
> 
>   [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
eval is _not_ clever. Try: /msg greybot eval
..or check http://wooledge.org:8000/BashFAQ/048
 
> This way, people can simply quote as they like:
> 
> DOCS="'filename with spaces' filename_without_space doc/*"
>
Yeuch.

> or also
> 
> DOCS="just_one_filename_without_special_characters"
>
You don't need quotes there.
 
> or also - when Push from /usr/bin/functions-eix.sh is used
> (which might be implemented simpler without using other functions):
> 
> Push DOCS 'filename with spaces' filename_without_space "${S}"/doc/*
> 
Or just do DOCS+=(foo/* someFile 'some other File') at any point.

BASH arrays will cope with *any* character apart from NUL, which isn't
allowed in filenames. Can you _guarantee_ the same?

For instance, what if some crazy designer puts a file called:
Vaeth's "Latest" Hits
..in that doc dir; what happens after the Push function has been called and,
only at a later stage, the eval is run on the result of that glob
expansion?
 
> Not only has this the advantage that it is POSIX (and thus does not
> force ebuilds to use the particular shell "bash" - a policy which perhaps
> some day might be changed: It is dangerous to depend on a particular
> implementation),

I'm not getting back into that discussion, since we had the same one over a
period of months already. Ebuilds require BASH; get over it. If we could
move ahead with actually using BASH properly (and cleanly) it would be
nice. BASH is as portable as GNU make is, and you clearly have no issue
depending on that, and Python or C++.

BTW, POSIX sh doesn't need ${DOCS} or ${S} either, you're just wasting
characters.

> the array-less solution is also much simpler to 
> implement, easy to understand from the source, and clearer in usage.

Not to me it's not, it looks awful, to read and to type, as well as being
fragile.

Furthermore you're bringing eval into the script new people are going to
look at to learn from (it's core functionality, fulfilling a basic task)
which is dangerous from a long-term pov, imo. Leave aside having to
maintain that cruft.

> Case distinctions like
> 
>> if isArr DOCS; then
>>    ((${#DOCS[@]})) && dodoc "${DOCS[@]}"
>> else [[ $DOCS ]] && dodoc $DOCS
>> fi
> 
> are just awful.

Actually if you factor out that isArr is a utility function (exactly like
Push) that code is very easy to follow, as well as coping with all
filenames, and itself would be part of a lib function. The only reason to
have the check is for backward-compatibility, or to allow people to use
whichever they feel most comfortable with.

One might not know how to count/use arrays in BASH, fair enough; that's how.
Given that basic knowledge[1] of the tool used to write ebuilds since the
very beginning, I cannot see how that is hard to follow.

I'm willing to bet your sh scripts aren't really as portable as you think.
If you want to see how portable sh is done, read:
http://sources.redhat.com/autobook/autobook/autobook_210.html#SEC210
(all of it) and then try to persuade us that we should be writing ebuilds
like that.

If you want to do that kind of thing, much better imo to do another type of
ebuild, eg a pbuild using Python, and only call sh when absolutely
necessary, if at all.

BTW, thanks for eix; it's a lovely utility.

[1] http://wooledge.org/mywiki/BashFAQ/005

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Sun, 21 Sep 2008, Steve Long wrote:

> Vaeth wrote:
>> let me remark that the more clever way to this is
>> [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"

> [...]
> BASH arrays will cope with *any* character apart from NUL, which
> isn't allowed in filenames. Can you _guarantee_ the same?

It seems to me that both bash arrays and "eval" are overkill here.

After all, we are talking about a _default_ behaviour, and IMHO this
should be kept as simple as possible. I doubt that there are many
ebuilds installing files with strange names in /usr/share/doc. The few
(if any) doing that might need a more complicated src_install anyway.

My system may not be representative, but here are _no_ files
containing spaces in /usr/share/doc:

$ find /usr/share/doc | wc
 104936  104936 7522127

(Note that the number of lines and words are equal.)

Ulrich

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Kent Fredric]

On Mon, Sep 22, 2008 at 1:04 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> >>>>> On Sun, 21 Sep 2008, Steve Long wrote:
>
> > Vaeth wrote:
> >> let me remark that the more clever way to this is
> >> [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
> > [...]
> > BASH arrays will cope with *any* character apart from NUL, which
> > isn't allowed in filenames. Can you _guarantee_ the same?
>
> It seems to me that both bash arrays and "eval" are overkill here.
>
> After all, we are talking about a _default_ behaviour, and IMHO this
> should be kept as simple as possible. I doubt that there are many
> ebuilds installing files with strange names in /usr/share/doc. The few
> (if any) doing that might need a more complicated src_install anyway.
>
> My system may not be representative, but here are _no_ files
> containing spaces in /usr/share/doc:
>
> $ find /usr/share/doc | wc
>  104936  104936 7522127
>
> (Note that the number of lines and words are equal.)
>
> Ulrich
>

find /usr/share/doc/ -wholename "* *"
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2

And in case somebody gets space-phobic on a different directory :

find /usr/ -wholename "* *"
/usr/kde/4.2/share/applnk/Development/Web Development
/usr/kde/svn/share/applnk/Development/Web Development
/usr/share/applnk/Development/Web Development
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
/usr/share/lcms/profiles/sRGB Color Space Profile.icm
/usr/share/mixxx/( Lots here )


 ¢¢ ( Apps that break on spaces are embarrasing )
--
Kent

ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil kdrtf@gma.com"[(2*x)..(2*x+1)]}'

http://kent-fredric.fox.geek.nz

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Mon, 22 Sep 2008, Kent Fredric wrote:

> find /usr/share/doc/ -wholename "* *"
> /usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2

Yes, and if you look into src_install of the ebuild, it does:
    dodoc doc/*.txt

So a simple "dodoc ${DOCS}" with DOCS="... doc/*.txt ..." would work
even in this case. No need for arrays.

Ulrich

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Ulrich Mueller wrote:

>>>>>> On Mon, 22 Sep 2008, Kent Fredric wrote:
> 
>> find /usr/share/doc/ -wholename "* *"
>> /usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
> 
> Yes, and if you look into src_install of the ebuild, it does:
>     dodoc doc/*.txt
>
Well at least we've established that it can and does happen.
 
> So a simple "dodoc ${DOCS}" with DOCS="... doc/*.txt ..." would work
> even in this case. No need for arrays.
> 
That works for that specific case, yes, but it's still not a general
solution, which is what BASH arrays were invented for. For instance, an
ebuild author cannot specifically include a file with spaces, and ignore
all the other files in the same directory.

To show what I mean, given this one-liner in a terminal:
args() { (($#)) || return; echo "$# params:"; local i n=1; for i; do
echo "$n: $i"; let n++; done; }

..try these (where doc is a subdirectory of your current folder, and mem*
matches some files in it):
DOCS="doc/mem* foo"; args $DOCS
DOCS="doc/mem* 'foo bar baz'"; args $DOCS
DOCS=(doc/mem* 'foo bar baz'); args "${DOCS[@]}"

Globs work fine for a function call, or indeed for adding to an array. As
soon as you try to indirect via a variable, it has to be an array if you
want to be safe with filenames, for the general case. The same applies to
dynamic commands. See:
http://wooledge.org:8000/BashFAQ/040 and:
http://wooledge.org:8000/BashFAQ/050

Given that we're using BASH, it seems strange to preclude useful constructs.
It's a bit like telling someone to use Python without dicts (or even lists,
given how basic arrays are to virtually every programming language.) It's
much simpler to write scripts that will work with anything, and be able to
rely on them, than have to fix or work round them later.

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Sun, 21 Sep 2008, Steve Long wrote:

> That works for that specific case, yes, but it's still not a general
> solution, which is what BASH arrays were invented for. For instance,
> an ebuild author cannot specifically include a file with spaces, and
> ignore all the other files in the same directory.

The better solution would be to rename a such strange files ...
How about an "edetox"? ;-)

And I still don't see why we would need the most general solution for
a *default* function. There's always the possibility to write your own
src_install() for the few ebuilds that need it.

Ulrich

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Ulrich Mueller wrote:

>>>>>> On Sun, 21 Sep 2008, Steve Long wrote:
> 
>> That works for that specific case, yes, but it's still not a general
>> solution, which is what BASH arrays were invented for. For instance,
>> an ebuild author cannot specifically include a file with spaces, and
>> ignore all the other files in the same directory.
> 
> The better solution would be to rename a such strange files ...
> How about an "edetox"? ;-)
>
Heh, I like the name (it brings lots of ideas to mind, none of them very
achievable ;) but you get into the issue that you're changing the upstream
naming, which goes against the principle of source transparency I
personally love. It makes dealing with upstream projects much easier.
 
> And I still don't see why we would need the most general solution for
> a *default* function. There's always the possibility to write your own
> src_install() for the few ebuilds that need it.
> 
? Generality for lib functions seems like a desirable attribute to me.
If we handle the general case with the defaults, it means less need for
anyone to write more code, allowing them to focus on the interesting stuff
and keeping the tree smaller. If we never have to worry about whether the
base will cope with filenames, and only about quoting our own stuff, it
makes development quicker.

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Thomas Sachau]

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

Ulrich Mueller schrieb:
>>>>>> On Sun, 21 Sep 2008, Steve Long wrote:
> 
>> That works for that specific case, yes, but it's still not a general
>> solution, which is what BASH arrays were invented for. For instance,
>> an ebuild author cannot specifically include a file with spaces, and
>> ignore all the other files in the same directory.
> 
> The better solution would be to rename a such strange files ...
> How about an "edetox"? ;-)
> 
> And I still don't see why we would need the most general solution for
> a *default* function. There's always the possibility to write your own
> src_install() for the few ebuilds that need it.
> 
> Ulrich
> 
> 

I aggree with Ulrich in this case. This is just a suggestion for a default src_install funcion,
nothing that should cover every possible case. So if you have some special DOC that does not work
with the default install, you can still do it the normal way. So my suggestion for a default
src_install:

default_src_install() {
        if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
                if emake DESTDIR="${D} install || einstall ; then
                        die "install failed"
                else
                        if [[ -n ${DOCS} ]]; then
                                dodoc ${DOCS} || die "dodoc failed"
                        fi
                fi
        fi
}

Any more comments? Good? Bad? Interested?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Bo Ørsted Andresen]

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

On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
> default_src_install() {
>         if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
>                 if emake DESTDIR="${D} install || einstall ; then
>                         die "install failed"
>                 else
>                         if [[ -n ${DOCS} ]]; then
>                                 dodoc ${DOCS} || die "dodoc failed"
>                         fi
>                 fi
>         fi
> }
>
> Any more comments? Good? Bad? Interested?

Now figure out the four flaws in the above code.

-- 
Bo Andresen

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

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Alec Warner]

On Tue, Sep 23, 2008 at 4:21 PM, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
> On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
>> default_src_install() {
>>         if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
>>                 if emake DESTDIR="${D} install || einstall ; then
>>                         die "install failed"
>>                 else
>>                         if [[ -n ${DOCS} ]]; then
>>                                 dodoc ${DOCS} || die "dodoc failed"
>>                         fi
>>                 fi
>>         fi
>> }
>>
>> Any more comments? Good? Bad? Interested?
>
> Now figure out the four flaws in the above code.

Why not be helpful and point them out?

I would call your comment 'UnGentooey', if I may use a work term.  I
don't think saying there are flaws in a given piece of code is really
helpful to anyone.

-Alec

>
> --
> Bo Andresen
>

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Bo Ørsted Andresen]

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

On Wednesday 24 September 2008 07:28:07 Alec Warner wrote:
> > Now figure out the four flaws in the above code.
>
> Why not be helpful and point them out?
>
> I would call your comment 'UnGentooey', if I may use a work term.  I
> don't think saying there are flaws in a given piece of code is really
> helpful to anyone.

Because in this case it's so remarkably obvious that anybody who has the 
slightest clue about bash and who thought about it for more than three 
seconds should be able to see it on their own? Also for those who still 
couldn't see it just testing it would have caught three of the flaws..

-- 
Bo Andresen

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

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Nirbheek Chauhan]

On Wed, Sep 24, 2008 at 4:51 AM, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
> On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
>> default_src_install() {
>>         if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
>>                 if emake DESTDIR="${D} install || einstall ; then
>>                         die "install failed"
>>                 else
>>                         if [[ -n ${DOCS} ]]; then
>>                                 dodoc ${DOCS} || die "dodoc failed"
>>                         fi
>>                 fi
>>         fi
>> }
>>
>> Any more comments? Good? Bad? Interested?
>
> Now figure out the four flaws in the above code.

Even though IMO that comment is quite condescending, I'll list out the
flaws in that code:

>>         if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
[...]
>>         fi

- So if those makefiles don't exist, the package should just carry on
without installing anything?

>>                 if emake DESTDIR="${D} install || einstall ; then
>>                         die "install failed"

- It is quite useless to run *both* emake install and einstall.
Default are not supposed to be lazy-maintainer-proof. The maintainer
should make sure that the ebuild works with emake install, and *if* it
doesn't, use einstall
- The above code will cause a die when either one of emake install or
einstall are *successful*. The opposite behaviour is desired.

>>                 else
>>                         if [[ -n ${DOCS} ]]; then
>>                                 dodoc ${DOCS} || die "dodoc failed"
>>                         fi

- So, if emake install || einstall fails, one should just install the
docs? The opposite behaviour is desired.

If a default src_install is desired, it should cater to the most
common use-cases and leave it to the maintainer to override it if
desired.

default_src_install() {
    emake DESTDIR="${D}" install || die "emake install failed"
    if [ -n "${DOCS}" ]; then
        dodoc ${DOCS} || die "dodoc failed"
    else
        # No die here because we don't know if any of these exist
        dodoc AUTHORS ChangeLog NEWS README
    fi
}

-- 
~Nirbheek Chauhan

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Thomas Sachau]

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

Nirbheek Chauhan schrieb:
> On Wed, Sep 24, 2008 at 4:51 AM, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
>> On Tuesday 23 September 2008 21:39:52 Thomas Sachau wrote:
> 
>>>         if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> [...]
>>>         fi
> 
> - So if those makefiles don't exist, the package should just carry on
> without installing anything?

This is imho a good idea, else virtuals and meta packages would need an extra (empty) src_install().

> 
>>>                 if emake DESTDIR="${D} install || einstall ; then
>>>                         die "install failed"
> 
> - The above code will cause a die when either one of emake install or
> einstall are *successful*. The opposite behaviour is desired.

Eh, sure, my mistake.

> 
>>>                 else
>>>                         if [[ -n ${DOCS} ]]; then
>>>                                 dodoc ${DOCS} || die "dodoc failed"
>>>                         fi
> 
> - So, if emake install || einstall fails, one should just install the
> docs? The opposite behaviour is desired.

see above

> 
> If a default src_install is desired, it should cater to the most
> common use-cases and leave it to the maintainer to override it if
> desired.
> 
> default_src_install() {
>     emake DESTDIR="${D}" install || die "emake install failed"
>     if [ -n "${DOCS}" ]; then
>         dodoc ${DOCS} || die "dodoc failed"
>     else
>         # No die here because we don't know if any of these exist
>         dodoc AUTHORS ChangeLog NEWS README
>     fi
> }
> 

So what about this one?

default_src_install() {
	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
		emake DESTDIR="${D}" install || die "emake install failed"
        fi
	if [ -n "${DOCS}" ]; then
		dodoc ${DOCS} || die "dodoc failed"
	else
	        # No die here because we don't know if any of these exist
        	dodoc AUTHORS ChangeLog NEWS README
	fi
}


-- 
Thomas Sachau

Gentoo Linux Developer





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

[gentoo-dev] Usage of econf with an additional || die

[Thomas Sachau]

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

I see many ebuild that still use "econf || die", also econf should die by itself. Are there any
specific reasons for this? Some cases where econf does not die also it fails? Or some other reason
for this?

Some feedback on this would be nice.

Thanks
-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-dev] Usage of econf with an additional || die

[Vlastimil Babka]

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

Thomas Sachau wrote:
> I see many ebuild that still use "econf || die", also econf should die by itself. Are there any
> specific reasons for this? Some cases where econf does not die also it fails? Or some other reason
> for this?

My guess is that due to the general lack of consistency in what dies and
what not, people either make mistakes or just take the safe route?

Caster



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Usage of econf with an additional || die

[Peter Volkov]

В Вск, 28/09/2008 в 20:24 +0200, Thomas Sachau пишет:
> I see many ebuild that still use "econf || die", also econf should die by itself. Are there any
> specific reasons for this? Some cases where econf does not die also it fails? Or some other reason
> for this?

This || die is redundant. Personally I remove it in every package I
touch and I suggest others do the same. People use our tree to learn how
to write ebuilds, so it's good idea to have consistent syntax in our
ebuilds...

-- 
Peter.

Re: [gentoo-dev] Usage of econf with an additional || die

[Ben de Groot]

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

Peter Volkov wrote:
> В Вск, 28/09/2008 в 20:24 +0200, Thomas Sachau пишет:
>> I see many ebuild that still use "econf || die", also econf should die by itself. 
> 
> This || die is redundant. Personally I remove it in every package I
> touch and I suggest others do the same. People use our tree to learn how
> to write ebuilds, so it's good idea to have consistent syntax in our
> ebuilds...
> 
So, can we have a nice little table of which functions die by themselves
and which ones need || die added in ebuilds? Please?

Thanks,

-- 
Ben de Groot
Gentoo Linux developer (lxde, media, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__________________________________________________

yngwin@gentoo.org
http://ben.liveforge.org/
irc://chat.freenode.net/#gentoo-media
irc://irc.oftc.net/#lxde
__________________________________________________



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Usage of econf with an additional || die

[Jeremy Olexa]

Ben de Groot wrote:

> So, can we have a nice little table of which functions die by themselves
> and which ones need || die added in ebuilds? Please?
> 
> Thanks,
> 

A quick grep of /usr/lib/portage/bin clues you in that every function 
that is an external file does *not* die by itself. So, emake, do*, etc..

%% grep -c die * |grep -v ":0"
ebuild.sh:61
etc-update:14
isolated-functions.sh:18
misc-functions.sh:26
repoman:2

I believe this is because you can have those functions in a subshell and 
then die won't behave predictably. I'm sure some PM people will correct 
me if I am wrong. ;)

-Jeremy

Re: [gentoo-dev] Usage of econf with an additional || die

[Thomas Sachau]

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

Jeremy Olexa schrieb:
> Ben de Groot wrote:
> 
>> So, can we have a nice little table of which functions die by themselves
>> and which ones need || die added in ebuilds? Please?
>>
>> Thanks,
>>
> 
> A quick grep of /usr/lib/portage/bin clues you in that every function
> that is an external file does *not* die by itself. So, emake, do*, etc..
> 
> %% grep -c die * |grep -v ":0"
> ebuild.sh:61
> etc-update:14
> isolated-functions.sh:18
> misc-functions.sh:26
> repoman:2
> 
> I believe this is because you can have those functions in a subshell and
> then die won't behave predictably. I'm sure some PM people will correct
> me if I am wrong. ;)
> 
> -Jeremy
> 
> 

From my knowledge and experience with sunrise:

some functions that dont need "|| die":
epatch, econf, eqmake3, eqmake4

some functions that need "|| die":
emake, do*

Afaik die wont work in a subshell independent of how it is called, so the die from econf wont work,
but also the "emake || die" one would also not work.

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-dev] Usage of econf with an additional || die

[Matthias Schwarzott]

On Dienstag, 30. September 2008, Thomas Sachau wrote:
>
> From my knowledge and experience with sunrise:
>
> some functions that dont need "|| die":
> epatch, econf, eqmake3, eqmake4
>
> some functions that need "|| die":
> emake, do*
>
> Afaik die wont work in a subshell independent of how it is called, so the
> die from econf wont work, but also the "emake || die" one would also not
> work.

Well there might be some cases when die does not work fine, I am not sure.
But it IS designed to work in subshells.
Looking into /usr/lib/portage/bin/isolated-functions.sh: die basically calls
kill -s SIGTERM ${EBUILD_MASTER_PID}


and sigterm is catched in /usr/lib/portage/bin/ebuild.sh

# subshell die support
EBUILD_MASTER_PID=$$
trap 'exit 1' SIGTERM

and btw. econf is also implemented as a function in ebuild.sh so it even is 
executed inside the "main" ebuild bash process - no subshell here.

Regards
Matthias

Re: [gentoo-dev] Usage of econf with an additional || die

[Zac Medico]

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

Peter Volkov wrote:
> В Вск, 28/09/2008 в 20:24 +0200, Thomas Sachau пишет:
>> I see many ebuild that still use "econf || die", also econf should die by itself. Are there any
>> specific reasons for this? Some cases where econf does not die also it fails? Or some other reason
>> for this?
> 
> This || die is redundant. Personally I remove it in every package I
> touch and I suggest others do the same. People use our tree to learn how
> to write ebuilds, so it's good idea to have consistent syntax in our
> ebuilds...
> 

I suppose it depends on your notion of consistent. Does having econf
behave differently from every other function seem consistent to you? :)
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjiAckACgkQ/ejvha5XGaOAJgCeJKoJvmR2jxQvHZpaa6FplJ7c
fgYAn25YS4vGXahxC1QA3QmJR7yC3D/W
=da+4
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Nirbheek Chauhan]

On Sat, Sep 27, 2008 at 3:47 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> So what about this one?
>
> default_src_install() {
>        if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
>                emake DESTDIR="${D}" install || die "emake install failed"
>        fi
>        if [ -n "${DOCS}" ]; then
>                dodoc ${DOCS} || die "dodoc failed"
>        else
>                # No die here because we don't know if any of these exist
>                dodoc AUTHORS ChangeLog NEWS README
>        fi
> }

This seems alright fine to me

Cheers,

~Nirbheek Chauhan

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Petteri Räty]

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

Nirbheek Chauhan kirjoitti:
> On Sat, Sep 27, 2008 at 3:47 PM, Thomas Sachau <tommy@gentoo.org> wrote:
>> So what about this one?
>>
>> default_src_install() {
>>        if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
>>                emake DESTDIR="${D}" install || die "emake install failed"
>>        fi
>>        if [ -n "${DOCS}" ]; then
>>                dodoc ${DOCS} || die "dodoc failed"
>>        else
>>                # No die here because we don't know if any of these exist
>>                dodoc AUTHORS ChangeLog NEWS README
>>        fi
>> }
> 
> This seems alright fine to me
> 
> Cheers,
> 
> ~Nirbheek Chauhan
> 

It's not. If you want to have default DOCS then you should loop through 
the items and check with [[ -e ]] before trying to install them.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Tue, 30 Sep 2008, Petteri Räty wrote:

>>> dodoc ${DOCS} || die "dodoc failed"
>> This seems alright fine to me

> It's not. If you want to have default DOCS then you should loop
> through the items and check with [[ -e ]] before trying to install
> them.

I'm not convinced that this is a good idea. Then you won't catch cases
where upstream removes or renames files.

Besides, dodoc already checks for -e by itself (and emits a warning if
the file does not exist).

So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
fail but the warning message would be preserved.

Ulrich

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

[Robert Buchholz]

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

On Sunday, 5. October 2008, Ulrich Mueller wrote:
> >>>>> On Tue, 30 Sep 2008, Petteri Räty wrote:
> >>>
> >>> dodoc ${DOCS} || die "dodoc failed"
> >>
> >> This seems alright fine to me
> >
> > It's not. If you want to have default DOCS then you should loop
> > through the items and check with [[ -e ]] before trying to install
> > them.
>
> I'm not convinced that this is a good idea. Then you won't catch cases
> where upstream removes or renames files.
>
> Besides, dodoc already checks for -e by itself (and emits a warning if
> the file does not exist).
>
> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
> fail but the warning message would be preserved.

I understood Petteri's comment to be related to the default case (i.e. the 
else-branch), and I have to agree there: Ebuilds that do not override 
src_install should not emit a warning when some ChangeLog file is missing 
that the ebuild never specified to install.

Robert

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

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Sun, 5 Oct 2008, Robert Buchholz wrote:

>> > It's not. If you want to have default DOCS then you should loop
>> > through the items and check with [[ -e ]] before trying to
>> > install them.

>> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
>> fail but the warning message would be preserved.

> I understood Petteri's comment to be related to the default case
> (i.e. the else-branch), and I have to agree there: Ebuilds that do
> not override src_install should not emit a warning when some
> ChangeLog file is missing that the ebuild never specified to
> install.

The default would be an empty DOCS variable, or did I miss something?

So if the ebuild includes non-existing files in DOCS, then why would
you want to suppress the warnings?

Ulrich

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

[Robert Buchholz]

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

On Sunday, 5. October 2008, Ulrich Mueller wrote:
> >>>>> On Sun, 5 Oct 2008, Robert Buchholz wrote:
> >> >
> >> > It's not. If you want to have default DOCS then you should loop
> >> > through the items and check with [[ -e ]] before trying to
> >> > install them.
> >>
> >> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
> >> fail but the warning message would be preserved.
> >
> > I understood Petteri's comment to be related to the default case
> > (i.e. the else-branch), and I have to agree there: Ebuilds that do
> > not override src_install should not emit a warning when some
> > ChangeLog file is missing that the ebuild never specified to
> > install.
>
> The default would be an empty DOCS variable, or did I miss something?

Correct.

> So if the ebuild includes non-existing files in DOCS, then why would
> you want to suppress the warnings?

I don't. My point was that the default action on an empty DOCS variable is 
to "dodoc AUTHORS ChangeLog NEWS README", and this should not emit 
warnings, because it is merely a heuristic.

To be clearer:
         else
-                # No die here because we don't know if any of these exist
-                dodoc AUTHORS ChangeLog NEWS README
+                for x in AUTHORS ChangeLog NEWS README; do
+                        if [ -e ${x} ]; then
+                                dodoc ${x} || die "dodoc ${x} failed"
+                        fi
+                done
         fi


Robert

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

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Sun, 5 Oct 2008, Robert Buchholz wrote:

>> So if the ebuild includes non-existing files in DOCS, then why would
>> you want to suppress the warnings?

> I don't. My point was that the default action on an empty DOCS
> variable is to "dodoc AUTHORS ChangeLog NEWS README", and this
> should not emit warnings, because it is merely a heuristic.

> To be clearer:
>          else
> -                # No die here because we don't know if any of these exist
> -                dodoc AUTHORS ChangeLog NEWS README
> +                for x in AUTHORS ChangeLog NEWS README; do
> +                        if [ -e ${x} ]; then
> +                                dodoc ${x} || die "dodoc ${x} failed"
> +                        fi
> +                done
>          fi

I agree. You (and Petteri) are absolutely right.

Ulrich

Re: [gentoo-dev] Default src_install for EAPI-2 or following EAPI

[Thomas Sachau]

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

Robert Buchholz schrieb:
> On Sunday, 5. October 2008, Ulrich Mueller wrote:
>>>>>>> On Sun, 5 Oct 2008, Robert Buchholz wrote:
>>>>> It's not. If you want to have default DOCS then you should loop
>>>>> through the items and check with [[ -e ]] before trying to
>>>>> install them.
>>>> So, maybe just do a 'dodoc "${DOCS}"' and omit the die? Then it won't
>>>> fail but the warning message would be preserved.
>>> I understood Petteri's comment to be related to the default case
>>> (i.e. the else-branch), and I have to agree there: Ebuilds that do
>>> not override src_install should not emit a warning when some
>>> ChangeLog file is missing that the ebuild never specified to
>>> install.
>> The default would be an empty DOCS variable, or did I miss something?
> 
> Correct.
> 
>> So if the ebuild includes non-existing files in DOCS, then why would
>> you want to suppress the warnings?
> 
> I don't. My point was that the default action on an empty DOCS variable is 
> to "dodoc AUTHORS ChangeLog NEWS README", and this should not emit 
> warnings, because it is merely a heuristic.
> 
> To be clearer:
>          else
> -                # No die here because we don't know if any of these exist
> -                dodoc AUTHORS ChangeLog NEWS README
> +                for x in AUTHORS ChangeLog NEWS README; do
> +                        if [ -e ${x} ]; then
> +                                dodoc ${x} || die "dodoc ${x} failed"
> +                        fi
> +                done
>          fi
> 
> 
> Robert

So what about this funcion for the next EAPI and also implementation in base.eclass?

default_src_install() {
	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
		emake DESTDIR="${D}" install || die "emake install failed"
	fi
	if [ -n "${DOCS}" ]; then
		dodoc ${DOCS} || die "dodoc failed"
	else
		for x in AUTHORS ChangeLog NEWS README; do
			if [ -e ${x} ]; then
				dodoc ${x} || die "dodoc ${x} failed"
			fi
		done
	fi
}

-- 
Thomas Sachau

Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Robert Buchholz]

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

On Tuesday 23 September 2008, Thomas Sachau wrote:
> Ulrich Mueller schrieb:
> > And I still don't see why we would need the most general solution
> > for a *default* function. There's always the possibility to write
> > your own src_install() for the few ebuilds that need it.
> >
> > Ulrich
>
> I aggree with Ulrich in this case. This is just a suggestion for a
> default src_install funcion, nothing that should cover every possible
> case. So if you have some special DOC that does not work with the
> default install, you can still do it the normal way. So my suggestion
> for a default src_install:
>
> default_src_install() {
>         if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
>                 if emake DESTDIR="${D} install || einstall ; then
>                         die "install failed"
>                 else
>                         if [[ -n ${DOCS} ]]; then
>                                 dodoc ${DOCS} || die "dodoc failed"
>                         fi
>                 fi
>         fi
> }
>
> Any more comments? Good? Bad? Interested?

Let's go with an even simpler default implementation:

default_src_install() {
	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
		emake DESTDIR="${D}" install || die "emake install failed"
        fi
	if [ -n "${DOCS}" ]; then
		dodoc ${DOCS} || die "dodoc failed"
	fi
}

It addresses the following issues:
* Do not run einstall if emake fails
* Run dodoc even if no Makefile is present, this might come in handy for
  ebuilds calling default()
* die dodoc failure case
* hopefully fix the flaws (not really) pointed out by zlin


Robert

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

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Santiago M. Mola]

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

El mié, 24-09-2008 a las 02:35 +0200, Robert Buchholz escribió:
> 
> Let's go with an even simpler default implementation:
> 
> default_src_install() {
> 	if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
> 		emake DESTDIR="${D}" install || die "emake install failed"
>         fi
> 	if [ -n "${DOCS}" ]; then
> 		dodoc ${DOCS} || die "dodoc failed"
> 	fi
> }
> 
> It addresses the following issues:
> * Do not run einstall if emake fails
> * Run dodoc even if no Makefile is present, this might come in handy for
>   ebuilds calling default()
> * die dodoc failure case
> * hopefully fix the flaws (not really) pointed out by zlin
> 

Looks far better. In my opinion, that would be an acceptable
implementation of default_src_install.

Regards,
-- 
Santiago Moisés Mola
Jabber: cooldwind@gmail.com | GPG: AAD203B5

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Thomas Sachau wrote:

> Ulrich Mueller schrieb:
>> And I still don't see why we would need the most general solution for
>> a *default* function. There's always the possibility to write your own
>> src_install() for the few ebuilds that need it.
>> 
> I aggree with Ulrich in this case.

As I said; generality in lib functions seems like a useful thing. There's a
quote I read from what is imo a classic computing text[1] (from the 70s,
never seen it referenced in any papers or anything):

"Why do we never have time to do it right,
but always plenty of time to do it over."

>                 if emake DESTDIR="${D} install || einstall ; then
missing " Don't those braces make it tricky.. ;p

> Any more comments? Good? Bad? Interested?

Given that we're okay relying on BASH, I don't think we should be scared to
use BASH effectively. Gentoo ebuild.sh should be a shining example of how
BASH is done, after eight years, not something that makes #bash folk laugh.

(I know this to be true, as when I started learning BASH, I tried dropping a
few of the lines in the channel to find out what was going on. It amazes me
that #bash is not mentioned in any of the Gentoo developer documentation,
afaict.)

In this case, you're saying "oh anyone who wants something that copes with
all filenames can do their own." IOW to do it right, we'll have to do it
over, further down the line.

BASH includes the facilities to do it right, as part of its design.

[1] "Program Style, Design, Efficiency, Debugging and Testing" van Tessel
(Prentice-Hall, 1974)

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Ulrich Mueller]

>>>>> On Wed, 24 Sep 2008, Steve Long wrote:

> As I said; generality in lib functions seems like a useful thing.

Other ebuild variables are space separated lists, so why should DOCS
be an exception?

So far nobody has shown a real-life example of an existing ebuild that
could profit from the array syntax.

> There's a quote I read from what is imo a classic computing text[1]
> (from the 70s, never seen it referenced in any papers or anything):

> "Why do we never have time to do it right,
> but always plenty of time to do it over."

"Entia non sunt multiplicanda praeter necessitatem."
 - Joh. Clauberg (1654)

Ulrich

[gentoo-dev] OT: Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Ulrich Mueller wrote:

>> As I said; generality in lib functions seems like a useful thing.
> 
> Other ebuild variables are space separated lists, so why should DOCS
> be an exception?
>
Because we're doing it right this time, while allowing existing usage. IOW
you can quite happily continue to use your space-separated list and it
won't matter. If you do ever need a bit more, it'll already be in place. If
you never do, how will it hurt you?
 
> So far nobody has shown a real-life example of an existing ebuild that
> could profit from the array syntax.
>
I think Duncan answered the point quite while. In summary that's why for
instance no filenames with spaces (leave alone all the other characters you
can't deal with atm) can be safely handled by any of your ebuild structure,
unless it comes from a glob, and is never manipulated or referenced in and
of itself. (Unless you wish to go down the eval route, which believe me is
not fun at all.)

If you're saying "fine we don't need any more control in those packages"
nothing I can say will be of any use. (NB: packages not programs.) Are you
really arguing that reduced functionality is a good thing?
 
>> There's a quote I read from what is imo a classic computing text[1]
>> (from the 70s, never seen it referenced in any papers or anything):
> 
>> "Why do we never have time to do it right,
>> but always plenty of time to do it over."
> 
> "Entia non sunt multiplicanda praeter necessitatem."
>  - Joh. Clauberg (1654)
> 
"Let him who thinks it is not broken, not interrupt the person fixing it."
Chinese proverb (wrongly attributed to some Ancient Roman.)

[gentoo-dev] Re: OT: Re: Default src_install for EAPI-2 or following EAPI

[Steve Long]

Steve Long wrote:

> In summary that's why for
> instance no filenames with spaces (leave alone all the other characters
> you can't deal with atm) can be safely handled by any of your ebuild
> structure, unless it comes from a glob, and is never manipulated or
> referenced in and of itself. (Unless you wish to go down the eval route,
> which believe me is not fun at all.)
> 
Or Roy's shell function thing (ie every array is handled via a function
call.) Then we're arguing about how, not why, however (and BASH arrays are
much nicer to work with for scripts that aren't just glue.)

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Duncan]

Steve Long <slong@rathaus.eclipse.co.uk> posted
gbc5v2$50d$1@ger.gmane.org, excerpted below, on  Wed, 24 Sep 2008 02:34:33
+0100:

> "Why do we never have time to do it right, but always plenty of time to
> do it over."

> In this case, you're saying "oh anyone who wants something that copes
> with all filenames can do their own." IOW to do it right, we'll have to
> do it over, further down the line.

It seems to me, we're building a lib function.  As such, we can take the 
time to do it right, now, and won't have to worry about it again.  Asking 
someone to code their own solution if it's doing the same thing but with 
"complex" filenames is asking for trouble.  We already have designs for a 
good wheel and are now discussing asking people to design their own.  Why?

If we do it right in the default function, particularly since it can be 
called /as/ a default function in an expanded version if necessary, 
there's one less place to make brain-dead mistakes like that missing 
double-quote.

That said, as always, I'm quite aware I'm not the one actually 
implementing it, so I'm not going to throw stones regardless of how it's 
implemented.  I just know if I ever decide to take that step to Gentoo 
devhood, or even just for my own ebuilds, it's sure be nice to not even 
have to worry about whether there's spaces or weird chars in the name, 
period.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Alec Warner]

On Sat, Sep 20, 2008 at 11:18 PM, Vaeth
<vaeth@mathematik.uni-wuerzburg.de> wrote:
> Steve Long wrote:
>
>> Thomas Sachau wrote: [...]
>>
>> > [[ -n ${DOCS} ]] && dodoc ${DOCS}
> [...]
>>
>> It might be wise to use an array for DOCS there
>
> Since I have now seen suggestions for using arrays unnecessarily
> at least twice (see also
>  [RFC] Ability to pass arguments to src_configure/src_compile
> but I am only speaking about the usage of _arrays_ here),
> let me remark that the more clever way to this is
>
>  [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
> This way, people can simply quote as they like:
>
> DOCS="'filename with spaces' filename_without_space doc/*"
>
> or also
>
> DOCS="just_one_filename_without_special_characters"
>
> or also - when Push from /usr/bin/functions-eix.sh is used
> (which might be implemented simpler without using other functions):
>
> Push DOCS 'filename with spaces' filename_without_space "${S}"/doc/*
>
>
> Not only has this the advantage that it is POSIX (and thus does not
> force ebuilds to use the particular shell "bash" - a policy which perhaps
> some day might be changed: It is dangerous to depend on a particular
> implementation), the array-less solution is also much simpler to
> implement, easy to understand from the source, and clearer in usage.
> Case distinctions like

gentoo-x86 uses bash; the ebuilds, the eclasses, they all rely on it.
I'm pretty sure most package managers rely on bash as well, but I have
not looked at the code outside of portage to verify.

I really dislike ideas where the compelling argument is 'in the future
we may make a specific decision and that makes that one choice
easier.'  If switching to POSIX shell was on the road map for Gentoo
or Gentoo-x86 or any of the package managers; I would maybe buy your
argument.  But as far as I am aware it is not; so planning for future
decisions that currently are undecided is folly in my mind.

It is much more pragmatic to use bash now (since we already use it)
and utilize its features.

If you have a compelling argument for switching the entire tree to
POSIX then give it; however I'm pretty sure it is a difficult argument
to make (Uberlord tried to make it in the past and did not succeed).
Otherwise lets just roll with the bash implementation.

-Alec


>
>> isArr() [[ $(declare -p "$1" 2>/dev/null) = 'declare -a'* ]]
>> if isArr DOCS; then
>>    ((${#DOCS[@]})) && dodoc "${DOCS[@]}"
>> else [[ $DOCS ]] && dodoc $DOCS
>> fi
>
> are just awful.
>
>

[gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Duncan]

"Alec Warner" <antarus@gentoo.org> posted
b41005390809211835h39f5a359k571e9693f7db1630@mail.gmail.com, excerpted
below, on  Sun, 21 Sep 2008 18:35:04 -0700:

> gentoo-x86 uses bash; the ebuilds, the eclasses, they all rely on it.
> I'm pretty sure most package managers rely on bash as well, but I have
> not looked at the code outside of portage to verify.
> 
> I really dislike ideas where the compelling argument is 'in the future
> we may make a specific decision and that makes that one choice easier.'

> If you have a compelling argument for switching the entire tree to POSIX
> then give it; however I'm pretty sure it is a difficult argument to make
> (Uberlord tried to make it in the past and did not succeed). Otherwise
> lets just roll with the bash implementation.

++

This seems to be what it comes down to.  Based on past discussion, while 
individual devs can go POSIX and nobody's going to complain, indeed, 
they're likely to be respected for taking that position in regard to 
/their/ /own/ /code/, there's sufficient resistance to making /all/ devs 
favor POSIX over BASH that it's effectively not even rational to 
contemplate it at this time, nor is it likely to be for a dev generation 
or more.  Trying to do otherwise is /perceived/ as (note I didn't say it 
was the /intent/ of, only /perceived/ as) trying to force POSIX down the 
throat of others, and given the current state requiring bash, turns that 
respect for devs doing it for their own work on its head -- they're then 
seen as being an active danger to the ability of devs who don't 
differentiate between POSIX sh and BASH to continue as devs in good 
Gentoo standing, with the entirely predictable reaction being to oppose 
them at nearly any cost.

Which pretty much leaves Gentoo depending on BASH now and for the 
foreseeable future, and there's little point in debating it further or 
indeed, in "artificially" trying to reduce that dependence, except in 
one's own work if desired.  It's just not worth the fractious debates it 
causes, particularly when the conclusion is predetermined based on past 
iterations.  We've lost very good developers on this issue in the past.  
Let's not make it any more, OK?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman