1 |
On Sun, Jul 18, 2010 at 01:54:43AM +0000, Jorge Manuel B. S. Vicetto wrote: |
2 |
> this is being used in the tree already. |
3 |
|
4 |
Doesn't make it right ;) |
5 |
|
6 |
> IIRC, since the introduction of EAPI-2 in the tree, there were a few |
7 |
> solutions present to the dev ml and the one agreed by people was the |
8 |
> abuse of depend to have the PM fail on dependency resolution instead of |
9 |
> calling die on an eclass - which iirc is / was forbidden by PMS. |
10 |
|
11 |
PMS has no such restriction as far as I know (or can grep for). |
12 |
Regardless, if PMS *did* forbid die's in eclass global scope... pretty |
13 |
much it's there already (including for when EAPI isn't at the correct |
14 |
value). |
15 |
|
16 |
Basically, a die can be dealt with better than broken atom's- |
17 |
DEPEND=eapi-too-old definitely conflicts w/ PMS (invalid atom), if die |
18 |
does in this case... the lesser of two evils is die. |
19 |
|
20 |
If PMS doesn't conflict (which I'm pretty sure it doesn't), then that |
21 |
leaves die as the proper approach. |
22 |
|
23 |
|
24 |
> We can discuss the correctness of this use, but please take into account |
25 |
> it's already being used so until we have such a discussion we can't |
26 |
> "forbid" its use. |
27 |
|
28 |
Yes we can. The fact it slipped in via 3 places that no one noticed |
29 |
doesn't mean it's now considerable acceptable. This is part of what |
30 |
triggered my rant- the tree is large and vast, sometimes monsters |
31 |
manage to get added and lurk for a while. That doesn't make them |
32 |
defacto standard however. |
33 |
|
34 |
At the time of it's addition, it was invalid from the parsing |
35 |
standpoint- it shouldn't have been added in the first place because of |
36 |
that. |
37 |
|
38 |
As for converting it to die, that can be done _now_ without fallout- |
39 |
if anything was triggering that codepath bones should've been |
40 |
complaining about it (yet to hear any such complaints). |
41 |
|
42 |
~harring |