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 |