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
1 On Fri, Aug 06, 2010 at 05:15:15PM +0100, David Leverton wrote:
2 > On 5 August 2010 04:27, Brian Harring <ferringb@×××××.com> wrote:
3 > > If an EAPI adds a new global function that cannot set/influence EAPI,
4 > > PM's that don't support that EAPI will spit complaints about 'missing
5 > > command' during sourcing- however the PM will still see the EAPI value
6 > > is one it knows it doesn't support, and act accordingly.
7 >
8 > You're suggesting a system based around ebuilds running commands that
9 > don't exist and ignoring the errors, which is a pretty blatant hack.
10
11 It's called forwards compatibility, and is basically no different than
12 type -p usage- the sole diff is that in ebuild usage since you're just
13 pulling metadata as the first step, the existance check isn't needed
14 since that functionality can't influence/set EAPI. If you don't
15 support the EAPI result, complaining to the user about the steps
16 getting there is misinformative at best. If you do support that EAPI,
17 than bitch at the user with the errors.
18
19 As for 'blatant hack', if you've got no users nor preexisting ebuild
20 data, you can design whatever you want- it's quite easy to call things
21 blatant hacks if you can design things from scratch and not worry
22 about compatibility. This is a form of armchair quarterbacking.
23
24 EAPI did not have that luxury however, thus a pragmatic solution was
25 choosen. I've heard a lot of bitching from various folk about EAPI
26 over the years, but the fact is even with it's flaws (both in
27 process, people involved, and in original constraints) it still has
28 been rolling changes out- all the while without requiring people to
29 rewrite ebuilds from scratch, or continually track an unversioned
30 format that changes semi-monthly.
31
32 It'd be nice if people were to remember that rather than spending
33 their time bitching about it. Hindsight, I'd have done a few things
34 differently, but that's the nature of hindsight- specifically I
35 would've used an eapi function rather than var.
36
37
38 > While I don't think it's /absolutely/ out of the question, as I said
39 > earlier, I can see why some people would exclude it from consideration
40 > entirely.
41
42 Whether said people like it or not, it was a known decision at the
43 time of creation- including the scenario under discussion. One thing
44 you'll note about my posts is that I'll list out what is possible,
45 and state what should/shouldn't be done. Just because I personally
46 think something is complete shit doesn't mean I go telling folk it's
47 impossible. There's a difference between opinion and fact- you're
48 excusing opinion stated as fact, which is not correct. Fact is, this
49 technique does work even if certain folk have another approach they
50 want instead.
51
52 Either way, this trick does work, although PM's could stand some
53 tweaking in their stdout/stderr outputting to make it a bit more user
54 friendly, so g33 can be ironed out.
55
56 ~brian

Replies

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