public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-20 11:31 ` [gentoo-dev] Default src_install for EAPI-2 or following EAPI Thomas Sachau
@ 2008-09-20 12:12   ` Steve Long
  0 siblings, 0 replies; 28+ messages in thread
From: Steve Long @ 2008-09-20 12:12 UTC (permalink / raw
  To: gentoo-dev

Thomas Sachau wrote:

> I see, we have a default src_unpack and a default src_compile but a
> default src_install is still missing. Here is my suggestion (taken and
> modified from bug 33544):
> 
> src_install() {
> if [ -f Makefile -o -f GNUmakefile -o -f makefile ]; then
> emake DESTDIR=${D} install || die "emake install failed"

You need to quote $D there, eg: DESTDIR="$D" as it's a parameter to a
command there, not a temporary export (as: DESTDIR=$D emake.. would be.)

> [[ -n ${DOCS} ]] && dodoc ${DOCS}
> else
> einstall || die "einstall failed"
> [[ -n ${DOCS} ]] && dodoc ${DOCS}
> fi
> }
> 
> Any comments?

It might be wise to use an array for DOCS there, so that filenames with
spaces are dealt with correctly. (I'm thinking of all those lovely GUI
apps.)

To keep compatibility with space-separated values, I use this function:

isArr() [[ $(declare -p "$1" 2>/dev/null) = 'declare -a'* ]]

(Yes I know, it's fugly.)

So this kinda logic deals with both:
if isArr DOCS; then
   ((${#DOCS[@]})) && dodoc "${DOCS[@]}"
else [[ $DOCS ]] && dodoc $DOCS
fi

(There's no need to repeat it, just move it to after the previous if.)

That can easily be initialised with a glob, eg DOCS=("$S"/doc/*) (although I
recommend nullglob if doing so.)

[See http://wooledge.org:8000/BashFAQ/073 (half way down) if you need to
strip prefixes or the like.]





^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
       [not found]   ` <be9Lf-478-5@gated-at.bofh.it>
@ 2008-09-21  6:18     ` Vaeth
  2008-09-21 11:44       ` Thomas Anderson
                         ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Vaeth @ 2008-09-21  6:18 UTC (permalink / raw
  To: gentoo-dev

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.



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21  6:18     ` [gentoo-dev] " Vaeth
@ 2008-09-21 11:44       ` Thomas Anderson
  2008-09-21 12:03       ` [gentoo-dev] " Steve Long
  2008-09-22  1:35       ` Alec Warner
  2 siblings, 0 replies; 28+ messages in thread
From: Thomas Anderson @ 2008-09-21 11:44 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 12:03       ` [gentoo-dev] " Steve Long
@ 2008-09-21 13:04         ` Ulrich Mueller
  2008-09-21 17:30           ` Kent Fredric
  0 siblings, 1 reply; 28+ messages in thread
From: Ulrich Mueller @ 2008-09-21 13:04 UTC (permalink / raw
  To: gentoo-dev

>>>>> 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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 13:04         ` [gentoo-dev] " Ulrich Mueller
@ 2008-09-21 17:30           ` Kent Fredric
  2008-09-21 18:50             ` Ulrich Mueller
  0 siblings, 1 reply; 28+ messages in thread
From: Kent Fredric @ 2008-09-21 17:30 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 17:30           ` Kent Fredric
@ 2008-09-21 18:50             ` Ulrich Mueller
  2008-09-21 20:23               ` Steve Long
  0 siblings, 1 reply; 28+ messages in thread
From: Ulrich Mueller @ 2008-09-21 18:50 UTC (permalink / raw
  To: gentoo-dev

>>>>> 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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 18:50             ` Ulrich Mueller
@ 2008-09-21 20:23               ` Steve Long
  2008-09-21 20:46                 ` Ulrich Mueller
  0 siblings, 1 reply; 28+ messages in thread
From: Steve Long @ 2008-09-21 20:23 UTC (permalink / raw
  To: gentoo-dev

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.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 20:23               ` Steve Long
@ 2008-09-21 20:46                 ` Ulrich Mueller
  2008-09-21 21:10                   ` Steve Long
  2008-09-23 19:39                   ` Thomas Sachau
  0 siblings, 2 replies; 28+ messages in thread
From: Ulrich Mueller @ 2008-09-21 20:46 UTC (permalink / raw
  To: gentoo-dev

>>>>> 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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 20:46                 ` Ulrich Mueller
@ 2008-09-21 21:10                   ` Steve Long
  2008-09-23 19:39                   ` Thomas Sachau
  1 sibling, 0 replies; 28+ messages in thread
From: Steve Long @ 2008-09-21 21:10 UTC (permalink / raw
  To: gentoo-dev

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.





^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Re: Default src_install for EAPI-2 or following EAPI
       [not found]       ` <bew51-7fR-11@gated-at.bofh.it>
@ 2008-09-21 22:11         ` Vaeth
  2008-09-22  0:35           ` [gentoo-dev] " Steve Long
  0 siblings, 1 reply; 28+ messages in thread
From: Vaeth @ 2008-09-21 22:11 UTC (permalink / raw
  To: gentoo-dev

Steve Long wrote:

> Vaeth wrote:
>
> > 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 is not at all related with my remark:
We were speaking about the variable DOCS, which is supposed to be
defined by a package author, not by an unreliable source.
Of course, unreliable data here may allow execution of arbitrary code,
but the package author can execute what he wants anyway.

> > This way, people can simply quote as they like:
> > 
> > DOCS="'filename with spaces' filename_without_space doc/*"
> >
> Yeuch.

Well: DOCS=('filename with spaces' filename_without_space doc/*)
I cannot see much difference: ( ) vs. " " would optically IMHO not be a
reason to discuss, but the former works only in bash, the latter
practically everyhwere (and so shell programmers should be used to the
latter notation anyway).

> > or also
> > 
> > DOCS="just_one_filename_without_special_characters"
> >
> You don't need quotes there.

This is true, but I wanted to show the way most people will use it.

> > 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.

So the difference is saving two tokens. Is this worth to cement
bash-dependency forever in many scripts?

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

Yes, Push does _guarantee_ the same. It is actually rather simple to
implement: It puts its argument in '...', separated by spaces,
but replaces ' in the arguments before by '\'' (the last part is a bit
tricky to do in POSIX [although not really hard - only in functions-eix.sh
this is lengthy, because a more general replacement function is used
there]. For the time being, I would not even argue against implementing
Push in a sourced script in bash: This is only one place to change if one
wants more compatibility later on).

> For instance, what if some crazy designer puts a file called:
> Vaeth's "Latest" Hits
> ..in that doc dir

no problem at all.

> Ebuilds require BASH; get over it.

My remark concerning arrays was meant to be general, not specific for
ebuilds/portage only (although I couldn't find a passage in the bible
where god claimed that ebuilds have to require bash. Actually, 99% of
the ebuilds would not need bash, if they would be modified in a completely
trivial ways (for the remaining 1% it would need a bit more work)).
If one encourages people to write ebuilds compatible, maybe even for
portage some day a change is realistic (although I am completely aware
that this is not a reasonable project for the near future).

> BASH is as portable as GNU make is, and you clearly have no issue
> depending on that, and Python or C++.

Do you know which shell might be preferrable in 5 years or 10 years?
Bets are good that thos shell will at least support POSIX;
bets are worse that this shell will support the bash-specific
treatment of arrays.

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

Yes, but that's the gentoo-recommended way to write variables -
no need to change the style just for changing it.

> > 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.

Yes, two symbols to type more is a nightmare :)
"Fragile" is not the case as I showed above.

> 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)

So why should people learn bashisms instead of compatible shell
programming? Eval is not bad in itself. It is only bad if used on
uncontrolled data which I never suggested. (Actually, a warning in an
portage manpage might be didactically more effective concerning the
dangers of the uncontrolled usage of eval than many shell introductions.)

> >> 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

Maybe my explanation was unclear here: I am not speaking about the code.
I am speaking about the way it behaves.
  DOCS='"a b"'   -> two files `"a' and `b"'
  DOCS=('"a b"') -> one file `"a b"'
this is just creating confusion by special cases.
If you say instead the argument is eval'ed, everybody who knows any shell
knows what is going on and that you have to quote correspondingly.
And the case distinction is necessary, since for arrays you cannot
shortcut (i.e. you can _never_ avoid the ( ) part) - for variables
you can (as you mentioned, in most cases you can even avoid the " " part).

> 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.

This is an old rhetorical trick (I don't know its name in English):
You impute that I claimed things which I never said - of course, then it
is easy for you to prove that these things are wrong.
I _never_ suggested to use code from stone-age for ebuilds (I did more
for the eix scripts, and I think that I succeeded meanwhile for all
architectures supported by gentoo, but I did never suggest this for
everybody. BTW: Even for these architectures only very few differences
from POSIX arose - these really old shells which do not have even
functions or other odd bugs seem to have really extinct. But this is a
different topic).

However, I strongly suggest to avoid bashisms unless absolutely
necessary and reasonable. There are scripts where this is reasonable,
but far too many scripts which use it do not belong to this category.
Using arrays to pass parameters is one of the cases of unnecessary usage
(although this is not widely known - that's that main reason why I posted
the remark).



^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Re: Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 22:11         ` [gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI Vaeth
@ 2008-09-22  0:35           ` Steve Long
  2008-09-22  8:25             ` [gentoo-dev] " Duncan
  0 siblings, 1 reply; 28+ messages in thread
From: Steve Long @ 2008-09-22  0:35 UTC (permalink / raw
  To: gentoo-dev

[Sorry for length]
Vaeth wrote:

> Steve Long wrote:
> 
>> Vaeth wrote:
>>
>> > 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 is not at all related with my remark:
> We were speaking about the variable DOCS, which is supposed to be
> defined by a package author, not by an unreliable source.
> Of course, unreliable data here may allow execution of arbitrary code,
> but the package author can execute what he wants anyway.
>
My point wasn't about security so much as the fact that the author has to
worry about how the filenames will be interpreted. You state that
saying "it will be eval'ed" is enough. I disagree, as it makes it trickier
to handle.
 
>> > This way, people can simply quote as they like:
>> > 
>> > DOCS="'filename with spaces' filename_without_space doc/*"
>> >
>> Yeuch.
> 
> Well: DOCS=('filename with spaces' filename_without_space doc/*)
> I cannot see much difference: ( ) vs. " " would optically IMHO not be a
> reason to discuss, but the former works only in bash, the latter
> practically everyhwere (and so shell programmers should be used to the
> latter notation anyway).
>
That's the thing though; most Gentoo devs don't appear to be shell
programmers, and certainly not POSIX sh ones. BASH is simply much more
convenient to work with, especially if you are used to another language
(that has arrays for example.) That convenience adds up to saved time and
cleaner code.

Again, your formulation only works with eval. It doesn't work easily as a
generic thing; it requires thinking about, mental effort from devs who are
already overstretched. I guess it comes down to the debate over saving
programmer time vs CPU time.
 
>> > or also
>> > 
>> > DOCS="just_one_filename_without_special_characters"
>> >
>> You don't need quotes there.
> 
> This is true, but I wanted to show the way most people will use it.
>
Sure, but people should also be learning when quotes are needed and when
not; that is fundamental to shell-scripting after all?
 
>> > 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.
> 
> So the difference is saving two tokens. Is this worth to cement
> bash-dependency forever in many scripts?
>
No, my point was that it's part of basic BASH syntax, so anyone looking at
it who knows BASH knows exactly what it does, without having to dig through
an eclass or the like to make sure. It's cleaner to work with in the lib
code too.
 
>> BASH arrays will cope with *any* character apart from NUL, which isn't
>> allowed in filenames. Can you _guarantee_ the same?
> 
> Yes, Push does _guarantee_ the same. It is actually rather simple to
> implement: It puts its argument in '...', separated by spaces,
> but replaces ' in the arguments before by '\'' (the last part is a bit
> tricky to do in POSIX [although not really hard - only in functions-eix.sh
> this is lengthy, because a more general replacement function is used
> there]. For the time being, I would not even argue against implementing
> Push in a sourced script in bash: This is only one place to change if one
> wants more compatibility later on).
>
Cool, I've seen that trick in makefiles (kernel uses it for echoing cmds
iirc.) If you're stuck with a shell that only implements a "stone-age"
standard, designed to allow a base common-denominator 15 or 20 years ago,
fair enough ;p
 
>> Ebuilds require BASH; get over it.
> 
> My remark concerning arrays was meant to be general, not specific for
> ebuilds/portage only (although I couldn't find a passage in the bible
> where god claimed that ebuilds have to require bash.
Yes, hyperbole aside: ebuilds have been built on BASH from the start.

> Actually, 99% of 
> the ebuilds would not need bash, if they would be modified in a completely
> trivial ways (for the remaining 1% it would need a bit more work)).
> If one encourages people to write ebuilds compatible, maybe even for
> portage some day a change is realistic (although I am completely aware
> that this is not a reasonable project for the near future).
>
The thing is those changes make the code harder to read and maintain, which
matters for the target scripters. It's important to be able to look at the
script and tell what it does quickly; it's also important to be able to
write and update it quickly and relatively easily.
 
>> BASH is as portable as GNU make is, and you clearly have no issue
>> depending on that, and Python or C++.
> 
> Do you know which shell might be preferrable in 5 years or 10 years?
> Bets are good that thos shell will at least support POSIX;
> bets are worse that this shell will support the bash-specific
> treatment of arrays.
>
ksh, zsh and bash all have arrays. Since POSIX came along, the development
(which moves forward, remember) of most next-generation shells (ie not
those aiming for the embedded space, but for general use) have all included
arrays.

Put it another way: do you believe the GNU shell in 5 or 10 years time will
not support arrays?
 
>> BTW, POSIX sh doesn't need ${DOCS} or ${S} either, you're just wasting
>> characters.
> 
> Yes, but that's the gentoo-recommended way to write variables -
> no need to change the style just for changing it.
>
Well OK, but imo no need to use it, since repoman deals fine with variables
without braces. Changing the style to make it easier to work with strikes
me as a good idea. (Especially when so many beginners think it means you
don't have to quote; it's just a distraction from learning what really
matters.)
 
>> > 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.
> 
> Yes, two symbols to type more is a nightmare :)
> "Fragile" is not the case as I showed above.
>
Again, it's not the two symbols. It's having to parse or write that string.
 
>> 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)
> 
> So why should people learn bashisms instead of compatible shell
> programming?

Precisely because bashisms are the features that have been added by people
who really know Unix to make their system administration easier. These are
the people who really know scripting in an environment where the scarcest
resource is human time.

>> Actually if you factor out that isArr is a utility function (exactly like
>> Push) that code is very easy to follow
> 
> Maybe my explanation was unclear here: I am not speaking about the code.
> I am speaking about the way it behaves.
>   DOCS='"a b"'   -> two files `"a' and `b"'
>   DOCS=('"a b"') -> one file `"a b"'
> this is just creating confusion by special cases.

No, it's providing two ways to specify a config variable. One is the
backward compatible manner, so that old ebuilds won't break, and people can
continue to use the method they're used to for simple things. The other is
the way for the ebuild author to specify more complex cases.

I know for a fact that users like having both. It's providing mechanism, and
not enforcing policy. "You must make sure your variables are in a fit state
to be eval'ed" is the opposite; it both takes away an option and restricts
what the user can easily do.

And you said yourself above you couldn't see much difference (although the
BASH version is a bit cleaner.) All I'll say is the BASH arrays mean you
always know what you're quoting; if you use 'a b' it's always one
parameter, exactly like all the other quoting you do.

> If you say instead the argument is eval'ed, everybody who knows any shell
> knows what is going on and that you have to quote correspondingly.
> And the case distinction is necessary, since for arrays you cannot
> shortcut (i.e. you can _never_ avoid the ( ) part) - for variables
> you can (as you mentioned, in most cases you can even avoid the " " part).
>
You can only avoid quotes (and I prefer '' unless I want variable expansion)
when it's a single token with no characters like < > ( ) & | or ; which
affect tokenisation (a $ obviously affects things too). [ ? or * don't
actually matter, since pathname expansion doesn't happen in assignment.

You can say "everyone knows what is going on" but beginners simply don't,
and even advanced sh scripters sometimes get their eval strings wrong.
Devoting the extra headspace when you're just trying to get a bug fixed, or
your first ebuild written, is just counter to maintaining a distribution
imo.

As for the case distinction, the ebuild author or maintainer doesn't need to
make it. It's only relevant for an eclass or base function which actually
handles the variable in question, either using it to carry out a task for
the ebuild author, or manipulating it.

It would be easy enough to convert it to array once after sourcing the
ebuild so that all functions could rely on it being an array, if that's
desired, so that the test would only be run once. Granted it would be a bit
more complex if it had to operate on a list of those variables, but it
wouldn't need eval, since BASH has syntax designed to obviate the need for
eval in nearly all cases.

>> 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.
> 
> This is an old rhetorical trick (I don't know its name in English):
> You impute that I claimed things which I never said - of course, then it
> is easy for you to prove that these things are wrong.
What, like saying my point was only about saving two tokens?

> I _never_ suggested to use code from stone-age for ebuilds
You did as far as I am concerned.

> (I did more 
> for the eix scripts, and I think that I succeeded meanwhile for all
> architectures supported by gentoo, but I did never suggest this for
> everybody.
I see; so you, a competent and knowledgeable sh scripter, are not even sure
whether your sh code works on every arch supported by Gentoo? Whereas BASH
is running on every single one of those and clearly ebuilds run on all of
them, or they wouldn't be supported. That reinforces my point about BASH
portability, which was actually why I posted the link to that doc.

> BTW: Even for these architectures only very few differences 
> from POSIX arose - these really old shells which do not have even
> functions or other odd bugs seem to have really extinct. But this is a
> different topic).
> 
> However, I strongly suggest to avoid bashisms unless absolutely
> necessary and reasonable. There are scripts where this is reasonable,
> but far too many scripts which use it do not belong to this category.

You seem to mixing up reasonable and necessary in the last sentence. Granted
ebuilds don't need bashisms in many cases; many could indeed be rewritten
to only use sh. Nonetheless, it's not about getting absolutely the most
efficient use of the processor, but about making it easy for people to
write and maintain ebuilds and eclasses.

Given things like the awkwardness and loss of flexibility[1] in only using [
it's entirely reasonable to specify that Gentoo ebuilds use BASH.

> Using arrays to pass parameters is one of the cases of unnecessary usage
> (although this is not widely known - that's that main reason why I posted
> the remark).

Thanks for the discussion, although I do feel we're covering old ground.[2]
Given that ebuilds need BASH, have always needed BASH, and will continue to
do so, can we get on with actually using BASH and not BASHiSH?

[1] http://wooledge.org:8000/BashFAQ/031
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/52102





^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21  6:18     ` [gentoo-dev] " Vaeth
  2008-09-21 11:44       ` Thomas Anderson
  2008-09-21 12:03       ` [gentoo-dev] " Steve Long
@ 2008-09-22  1:35       ` Alec Warner
  2008-09-22  8:22         ` Duncan
  2 siblings, 1 reply; 28+ messages in thread
From: Alec Warner @ 2008-09-22  1:35 UTC (permalink / raw
  To: gentoo-dev

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.
>
>



^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-22  1:35       ` Alec Warner
@ 2008-09-22  8:22         ` Duncan
  0 siblings, 0 replies; 28+ messages in thread
From: Duncan @ 2008-09-22  8:22 UTC (permalink / raw
  To: gentoo-dev

"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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-22  0:35           ` [gentoo-dev] " Steve Long
@ 2008-09-22  8:25             ` Duncan
  2008-09-24  1:13               ` [gentoo-dev] [project] " Steve Long
  0 siblings, 1 reply; 28+ messages in thread
From: Duncan @ 2008-09-22  8:25 UTC (permalink / raw
  To: gentoo-dev

Steve Long <slong@rathaus.eclipse.co.uk> posted
gb6pop$997$1@ger.gmane.org, excerpted below, on  Mon, 22 Sep 2008 01:35:57
+0100:

>> This is an old rhetorical trick (I don't know its name in English): You
>> impute that I claimed things which I never said - of course, then it is
>> easy for you to prove that these things are wrong.
> What, like saying my point was only about saving two tokens?
> 
>> I _never_ suggested to use code from stone-age for ebuilds
> You did as far as I am concerned.

Careful please, both of you.  This bit looks like it could be headed 
personal, and I don't believe that's in the interest of anyone.

-- 
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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-21 20:46                 ` Ulrich Mueller
  2008-09-21 21:10                   ` Steve Long
@ 2008-09-23 19:39                   ` Thomas Sachau
  2008-09-23 23:21                     ` Bo Ørsted Andresen
                                       ` (2 more replies)
  1 sibling, 3 replies; 28+ messages in thread
From: Thomas Sachau @ 2008-09-23 19:39 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-23 19:39                   ` Thomas Sachau
@ 2008-09-23 23:21                     ` Bo Ørsted Andresen
  2008-09-24  5:28                       ` Alec Warner
  2008-09-24  7:46                       ` Nirbheek Chauhan
  2008-09-24  0:35                     ` Robert Buchholz
  2008-09-24  1:34                     ` [gentoo-dev] " Steve Long
  2 siblings, 2 replies; 28+ messages in thread
From: Bo Ørsted Andresen @ 2008-09-23 23:21 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-23 19:39                   ` Thomas Sachau
  2008-09-23 23:21                     ` Bo Ørsted Andresen
@ 2008-09-24  0:35                     ` Robert Buchholz
  2008-09-24  8:26                       ` Santiago M. Mola
  2008-09-24  1:34                     ` [gentoo-dev] " Steve Long
  2 siblings, 1 reply; 28+ messages in thread
From: Robert Buchholz @ 2008-09-24  0:35 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  [project] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-22  8:25             ` [gentoo-dev] " Duncan
@ 2008-09-24  1:13               ` Steve Long
  2008-09-24  6:42                 ` [gentoo-dev] " Duncan
  0 siblings, 1 reply; 28+ messages in thread
From: Steve Long @ 2008-09-24  1:13 UTC (permalink / raw
  To: gentoo-dev; +Cc: gentoo-project

Duncan wrote:

> Steve Long <slong@rathaus.eclipse.co.uk> posted
> gb6pop$997$1@ger.gmane.org, excerpted below, on  Mon, 22 Sep 2008 01:35:57
> +0100:
> 
>>> This is an old rhetorical trick (I don't know its name in English): You
>>> impute that I claimed things which I never said - of course, then it is
>>> easy for you to prove that these things are wrong.
>> What, like saying my point was only about saving two tokens?
>> 
>>> I _never_ suggested to use code from stone-age for ebuilds
>> You did as far as I am concerned.
> 
> Careful please, both of you.  This bit looks like it could be headed
> personal, and I don't believe that's in the interest of anyone.
> 
Eh, I feel that's slightly taken out of context, in that we both smiled at
each other during the course of the discussion, and I wouldn't have made
such a long post if I hadn't both respected Vaeth and thought it was a
technical discussion (now that we have project. I'm cross-posting this for
for those who only follow dev; please follow up to project if you wish to
comment further.) I did thank him at the end too, to keep it civil.

Having said that, you're right that it could be read like that, and I
applaud your acting to stop any suggestion of it.

Guess I was being a bit Germanic ;-)





^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-23 23:21                     ` Bo Ørsted Andresen
@ 2008-09-24  5:28                       ` Alec Warner
  2008-09-24  9:01                         ` Bo Ørsted Andresen
  2008-09-24  7:46                       ` Nirbheek Chauhan
  1 sibling, 1 reply; 28+ messages in thread
From: Alec Warner @ 2008-09-24  5:28 UTC (permalink / raw
  To: gentoo-dev

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
>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-24  1:34                     ` [gentoo-dev] " Steve Long
@ 2008-09-24  6:38                       ` Ulrich Mueller
  2008-09-24  6:40                       ` Duncan
  1 sibling, 0 replies; 28+ messages in thread
From: Ulrich Mueller @ 2008-09-24  6:38 UTC (permalink / raw
  To: gentoo-dev

>>>>> 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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-24  1:34                     ` [gentoo-dev] " Steve Long
  2008-09-24  6:38                       ` [gentoo-dev] " Ulrich Mueller
@ 2008-09-24  6:40                       ` Duncan
  1 sibling, 0 replies; 28+ messages in thread
From: Duncan @ 2008-09-24  6:40 UTC (permalink / raw
  To: gentoo-dev

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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* [gentoo-dev]  Re: [project] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-24  1:13               ` [gentoo-dev] [project] " Steve Long
@ 2008-09-24  6:42                 ` Duncan
  0 siblings, 0 replies; 28+ messages in thread
From: Duncan @ 2008-09-24  6:42 UTC (permalink / raw
  To: gentoo-dev; +Cc: gentoo-project

Steve Long <slong@rathaus.eclipse.co.uk> posted
gbc4n1$2g1$1@ger.gmane.org, excerpted below, on  Wed, 24 Sep 2008 02:13:12
+0100:

>  we both smiled at each other

I missed that.  Thanks.  "Over and out."

-- 
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




^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-23 23:21                     ` Bo Ørsted Andresen
  2008-09-24  5:28                       ` Alec Warner
@ 2008-09-24  7:46                       ` Nirbheek Chauhan
  2008-09-27 10:17                         ` Thomas Sachau
  1 sibling, 1 reply; 28+ messages in thread
From: Nirbheek Chauhan @ 2008-09-24  7:46 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev]  Re: Default src_install for EAPI-2 or following EAPI
  2008-09-24  0:35                     ` Robert Buchholz
@ 2008-09-24  8:26                       ` Santiago M. Mola
  0 siblings, 0 replies; 28+ messages in thread
From: Santiago M. Mola @ 2008-09-24  8:26 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-24  5:28                       ` Alec Warner
@ 2008-09-24  9:01                         ` Bo Ørsted Andresen
  0 siblings, 0 replies; 28+ messages in thread
From: Bo Ørsted Andresen @ 2008-09-24  9:01 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-24  7:46                       ` Nirbheek Chauhan
@ 2008-09-27 10:17                         ` Thomas Sachau
  2008-09-29  5:16                           ` Nirbheek Chauhan
  0 siblings, 1 reply; 28+ messages in thread
From: Thomas Sachau @ 2008-09-27 10:17 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-27 10:17                         ` Thomas Sachau
@ 2008-09-29  5:16                           ` Nirbheek Chauhan
  2008-09-30 17:05                             ` Petteri Räty
  0 siblings, 1 reply; 28+ messages in thread
From: Nirbheek Chauhan @ 2008-09-29  5:16 UTC (permalink / raw
  To: gentoo-dev

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



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI
  2008-09-29  5:16                           ` Nirbheek Chauhan
@ 2008-09-30 17:05                             ` Petteri Räty
  0 siblings, 0 replies; 28+ messages in thread
From: Petteri Räty @ 2008-09-30 17:05 UTC (permalink / raw
  To: gentoo-dev

[-- 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 --]

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2008-09-30 17:05 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <beqsE-8pJ-13@gated-at.bofh.it>
     [not found] ` <beqsE-8pJ-15@gated-at.bofh.it>
     [not found]   ` <beqsE-8pJ-17@gated-at.bofh.it>
     [not found]     ` <beqsD-8pJ-11@gated-at.bofh.it>
     [not found]       ` <bew51-7fR-11@gated-at.bofh.it>
2008-09-21 22:11         ` [gentoo-dev] Re: Re: Default src_install for EAPI-2 or following EAPI Vaeth
2008-09-22  0:35           ` [gentoo-dev] " Steve Long
2008-09-22  8:25             ` [gentoo-dev] " Duncan
2008-09-24  1:13               ` [gentoo-dev] [project] " Steve Long
2008-09-24  6:42                 ` [gentoo-dev] " Duncan
     [not found] <bcwiO-7zO-1@gated-at.bofh.it>
     [not found] ` <be8YL-33V-3@gated-at.bofh.it>
     [not found]   ` <be9Lf-478-5@gated-at.bofh.it>
2008-09-21  6:18     ` [gentoo-dev] " Vaeth
2008-09-21 11:44       ` Thomas Anderson
2008-09-21 12:03       ` [gentoo-dev] " Steve Long
2008-09-21 13:04         ` [gentoo-dev] " Ulrich Mueller
2008-09-21 17:30           ` Kent Fredric
2008-09-21 18:50             ` Ulrich Mueller
2008-09-21 20:23               ` Steve Long
2008-09-21 20:46                 ` Ulrich Mueller
2008-09-21 21:10                   ` Steve Long
2008-09-23 19:39                   ` Thomas Sachau
2008-09-23 23:21                     ` Bo Ørsted Andresen
2008-09-24  5:28                       ` Alec Warner
2008-09-24  9:01                         ` Bo Ørsted Andresen
2008-09-24  7:46                       ` Nirbheek Chauhan
2008-09-27 10:17                         ` Thomas Sachau
2008-09-29  5:16                           ` Nirbheek Chauhan
2008-09-30 17:05                             ` Petteri Räty
2008-09-24  0:35                     ` Robert Buchholz
2008-09-24  8:26                       ` Santiago M. Mola
2008-09-24  1:34                     ` [gentoo-dev] " Steve Long
2008-09-24  6:38                       ` [gentoo-dev] " Ulrich Mueller
2008-09-24  6:40                       ` Duncan
2008-09-22  1:35       ` Alec Warner
2008-09-22  8:22         ` Duncan
2008-09-16  0:01 [gentoo-dev] Bugzilla3 and Bugzilla Survey 2008 Robin H. Johnson
2008-09-20 11:31 ` [gentoo-dev] Default src_install for EAPI-2 or following EAPI Thomas Sachau
2008-09-20 12:12   ` [gentoo-dev] " Steve Long

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox