Re: [gentoo-dev] RFC: Reviving GLEP33

[Brian Harring <ferringb@gmail.com>]

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

On Fri, Aug 06, 2010 at 05:15:15PM +0100, David Leverton wrote:
> On 5 August 2010 04:27, Brian Harring <ferringb@gmail.com> wrote:
> > If an EAPI adds a new global function that cannot set/influence EAPI,
> > PM's that don't support that EAPI will spit complaints about 'missing
> > command' during sourcing- however the PM will still see the EAPI value
> > is one it knows it doesn't support, and act accordingly.
> 
> You're suggesting a system based around ebuilds running commands that
> don't exist and ignoring the errors, which is a pretty blatant hack.

It's called forwards compatibility, and is basically no different than 
type -p usage- the sole diff is that in ebuild usage since you're just 
pulling metadata as the first step, the existance check isn't needed 
since that functionality can't influence/set EAPI.  If you don't 
support the EAPI result, complaining to the user about the steps 
getting there is misinformative at best.  If you do support that EAPI, 
than bitch at the user with the errors.

As for 'blatant hack', if you've got no users nor preexisting ebuild 
data, you can design whatever you want- it's quite easy to call things 
blatant hacks if you can design things from scratch and not worry 
about compatibility.  This is a form of armchair quarterbacking.

EAPI did not have that luxury however, thus a pragmatic solution was 
choosen.  I've heard a lot of bitching from various folk about EAPI 
over the years, but the fact is even with it's flaws (both in 
process, people involved, and in original constraints) it still has 
been rolling changes out- all the while without requiring people to 
rewrite ebuilds from scratch, or continually track an unversioned 
format that changes semi-monthly.

It'd be nice if people were to remember that rather than spending 
their time bitching about it.  Hindsight, I'd have done a few things 
differently, but that's the nature of hindsight- specifically I 
would've used an eapi function rather than var.


> While I don't think it's /absolutely/ out of the question, as I said
> earlier, I can see why some people would exclude it from consideration
> entirely.

Whether said people like it or not, it was a known decision at the 
time of creation- including the scenario under discussion.  One thing 
you'll note about my posts is that I'll list out what is possible, 
and state what should/shouldn't be done.  Just because I personally 
think something is complete shit doesn't mean I go telling folk it's 
impossible.  There's a difference between opinion and fact- you're 
excusing opinion stated as fact, which is not correct.  Fact is, this 
technique does work even if certain folk have another approach they 
want instead.

Either way, this trick does work, although PM's could stand some 
tweaking in their stdout/stderr outputting to make it a bit more user 
friendly, so g33 can be ironed out.

~brian

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