Re: [gentoo-dev] DEFAULT_* proposal

[Peter Volkov <pva@gentoo.org>]

В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет:
> This is a reposting of a call for discussion on DEFAULT_* variables.
> The original discussion was at [1].

How does this proposal answers concerns raised during last discussion?

I did my best and reread all the discussions and both proposals. I found
two reasons supporting this change is that it makes ebuilds more
"flexible"[1] or "much simpler"[2]. With all due respect I disagree.

1. Functions we have now are much more flexible then proposed arrays. Do
I need to think of some example of code that is impossible to do with
arrays but still possible with functions?

2. Much simpler? No, it's not:

(2.1) Such arrays do not not reduce the number of keys to be pressed.
They require even more typing for small ebuilds [3] (example proposed by
you, btw) and the only example which expose some improvement (presented
by Santiago M. Mola[4]) shows that we still didn't learned how to use
syntax we already have and (2.2) some extensions to the current syntax
will just complicate things. Look if you remove $myconf variable from
that ebuild[4], remove || die after econf and in EAPI=2 you can drop
emake || die you'll see that the gain is small even for such medium size
ebuild.

At the same time this new syntax make some things worse:

1. it hides real code under this variables.

2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
practice of using patches instead of sed.

3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
btw). (highlighting helps here but does not makes that variables easier
to read or type in?)

4. "it also conflates multiple concepts into a single variable name (the
function name, whether it's USE-dependent, and how the configure flag is
passed)." (-- Donnie Berkholz [6])

5. "One of the great things about ebuilds is that they're very natural
to write in most cases, if you can manage to build the program by hand.
Raising this barrier of entry for questionable benefit seems like a bad 
idea." (-- Donnie Berkholz [7])


So, why to reiterate this discussion without providing clear answer to
the above concerns?


At the same time default src_install is different proposal and having it
implemented is a good idea.


[1] http://article.gmane.org/gmane.linux.gentoo.devel/57990
[2] http://article.gmane.org/gmane.linux.gentoo.devel/58728
[3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990
[4] http://article.gmane.org/gmane.linux.gentoo.devel/57996
[5] http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html
[6] http://article.gmane.org/gmane.linux.gentoo.devel/58061
[7] http://article.gmane.org/gmane.linux.gentoo.devel/58051

-- 
Peter.