[gentoo-dev] Re: [RFC] Ability to pass arguments to src_configure/src_compile

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> posted
20080908231325.0846cead@snowmobile, excerpted below, on  Mon, 08 Sep 2008
23:13:25 +0100:

> On Mon, 8 Sep 2008 14:33:50 -0700
> Donnie Berkholz <dberkholz@g.o> wrote:
>>
>> 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. We don't need to make it any harder to begin contributing to
>> Gentoo.

Great point, Donnie.  One of the things I've appreciated about the ebuild 
format is how accessible it is... in comparison to say some spec file.  
Part of that of course is that it's right out there in the open, not tied 
up in some semi-transparent tarball, but part of it is certainly that 
it's reasonably close to simple bash, as well.

> So why are we making people know the exact ins and outs of
> reimplementing default functions, complete with knowledge of whether or
> not to use die, when all they need in most cases is to set a simple
> variable instead?
>
> What proportion of people do you think know whether or not you need a
> die with econf or emake?

This is a valid point as well.  However, for a user simply concerned with 
getting a functional ebuild so the package is tracked by the PM as 
opposed to not (or manually tracking with package.provided), an extra die 
or two, or even the lack thereof, and the docs and stuff, don't matter as 
much as something easily understood and written with little more than 
knowledge of bash and what's easily cribbed from a few existing ebuilds 
used as samples.

These rather arbitrary vars do make sense to someone with a bit more 
knowledge, but are going to be about as opaque as the proper use of die, 
etc.  What's worse, they make the simple-case ebuilds more difficult to 
crib from for the user-sysadmin simply interested in getting a functional 
ebuild that allows the packaging system knowledge of what he's 
installing.  This sort of person is likely to write the ebuild, test it, 
and when it works, be done with it, regardless of its "correctness", and 
ideally with as little pre-supposed knowledge as possible.  They don't 
care about dies, but will care if they have to spend another half hour 
diving into docs to figure out how to effectively translate 
the .configure --with/etc stuff into the appropriate vars.

> The DEFAULT_* variables make it *easier* to write packages because half
> the time you don't need to arse around writing src_* functions. Every
> src_* function written by someone is another place there can be a
> non-obvious screwup.

That's true for the dev, certainly, but they do presuppose certain 
additional pre-knowledge that our user-sysadmin above won't have 
immediately.

What's more worrying from the perspective of that person is that while 
all these new vars are optional, if devs (with that pre-knowledge) start 
using them as easier, pretty soon that person above isn't going to have 
any easily accessible simple ebuilds to crib from any more.  It's not 
directly apparent that those vars hold what would be fed to .configure 
more or less directly, without knowledge of the package the ebuild is 
for.  In ordered to get that knowledge, the newbie ebuild writer will be 
forced to either investigate the packages he's cribbing from the ebuilds 
of, or look up the PM/PMS/ebuild documentation.

At least with eclasses, once one knows about inherit (a pretty simple 
concept once people start looking at ebuilds), it's standard bash 
functionality and easy enough to lookup what those arbitrary vars 
actually do.  If we implement this, it's going to be locked away in the 
PM somewhere not so easily accessible.  Additional specialized knowledge 
will be necessary.

(Hmm... this argument went other than I intended.  I was planning to 
point out that usage of the vars was optional, and that our user-sysadmin 
wouldn't have to use them if they didn't want to... but then as I wrote, 
I realized it may be optional, but that doesn't help much if all the 
simple ebuilds he finds to crib from end up using the pre-knowledge 
required vars, leaving him nothing simple to crib from without that 
knowledge.  The accessibility level will have been reduced if this 
happens.)

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