Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: Reviving GLEP33
Date: Fri, 06 Aug 2010 17:30:08
Message-Id: 20100806172732.GA17578@hrair
In Reply to: Re: [gentoo-dev] RFC: Reviving GLEP33 by David Leverton
On Fri, Aug 06, 2010 at 05:15:15PM +0100, David Leverton wrote:
> On 5 August 2010 04:27, Brian Harring <ferringb@×××××.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

Replies

Subject Author
Re: [gentoo-dev] RFC: Reviving GLEP33 Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>