Paludis does not use the features environment variable, and performs testing by default with userprivs. Even when running with userprivs the test phase of mysql fails indicating that FEATURES=-userpriv is not allowed. Setting FEATURES=userpriv (which has no effect in paludis) is a workaround and the tests are performed. A better solution would be to actually test for user privs instead of checking for a portage-specific FEATURE flag, or have paludis export this FEATURE anytime it is running with effective userprivs. I don't want to start a war over which package should change - just wanted to point out that the issue exists. If it isn't already done the folks trying to create a common standard for package managers should define what variables can be expected by ebuilds to be present/meaningful and have package managers export them if they don't themselves use them (and have variables not defined in the spec not be used by ebuilds). I'll go and hide now, and I won't be offended if this bug gets WONTFIX'ed if it doesn't make sense to resolve this issue... Reproducible: Always
FEATURES=userpriv has existed and been documented for ages; not an ebuild problem.
Well, I'd certainly admit to not being a portage developer, but I couldn't find the EAPI specs anywhere (not sure if they're posted). Portage certainly happens to have a FEATURES flag, which certainly has been around forever, but I'm not aware of anything official that documents that all package managers need to support it. It just happens to be that until recently gentoo has only had one. I think the whole goal of the EAPI bit is so that the interface between ebuild and package manager can be formally documented so that stuff like this goes away. In any case, I don't have any religious attachment to what the correct behavior is - and if the EAPI ends up saying that the package manager must export FEATURES with "userpriv" being a possible flag that is exported that can be read by ebuilds I certainly won't have any issues with that. But, this is an issue in any case so I figured I'd point it out. And I agree that it isn't really an ebuild problem at the moment, although it could become one if the council adopts an EAPI that forbids the use of FEATURES in ebuilds (which I'm guessing won't happen).
The ebuild could test for [[ $UID -eq 0 ]] instead of FEATURES..
Reassigning to the herd since Stephen was retired as a Gentoo developer. See bug #64840 for reference.
changed to [[ $UID -eq 0 ]] in CVS.
