Well, long story short, we rely on USE=test being magical while it has no reason whatsoever to really be magical. I think we could at least sanitize this a bit by doing: RESTRICT="!test? ( test )" which would mean that tests can't be run if USE=test is disabled (and therefore the dependencies aren't satisfied.
I'm not sure to whom you meant to assign this bug.
*shrug* This is just another workaround which doesn't address the real issue. There shouldn't be a test USE flag, in the first place. Also the flag won't get less magical, unless Portage is changed not to enable it depending on FEATURES. What we really need is a TDEPEND variable (or a generalised DEPENDENCIES variable) for expressing src_test dependencies.
(In reply to Ulrich Müller from comment #2) > *shrug* This is just another workaround which doesn't address the real > issue. There shouldn't be a test USE flag, in the first place. Also the flag > won't get less magical, unless Portage is changed not to enable it depending > on FEATURES. If we grep the tree for ebuilds containing 'use test', then we find some ebuilds using this conditional inside src_compile. So, we should do a comprehensive analysis of the utility of 'use test' in src_compile before we decide to do away with the flag. Maybe it could be replaced with a tests_enabled function, or something like that. > What we really need is a TDEPEND variable (or a generalised DEPENDENCIES > variable) for expressing src_test dependencies. That would be nice for a new EAPI, but the RESTRICT="!test? ( test )" thing seems quite reasonable for existing EAPIs.
So anyone strongly against it before I push this further?
