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