The above package has been found to use FEATURES in at least one of its ebuilds. FEATURES is a portage specific package manager configuration variable not specified in PMS and cannot reliably be used in ebuilds or eclasses. Usually there are a number of ways to achieve the same thing though. In other cases, the usage of FEATURES in the ebuild is simply invalid. If you need to check whether "test" is in ${FEATURES}, you can test if the USE flag "test" is set, since it will be activated in that case. When you check for "userpriv" in ${FEATURES} you may be able to something like the following instead: if [[ ${EUID} -eq 0 ]]; then rootstuff else nonrootstuff fi Thanks
Created attachment 279499 [details, diff] Fix the behaviour for eapis other than 0 1 Not sure it's desired but as the substitution is already done for EAPI 1, why not do the same for 2 3 4 and future EAPIs
Ignore the above comment, I wonder how I managed to attach it to the wrong bug. See bug 283967
It would be good to have this issue fixed: it's getting quite old, and egrep -R "\bFEATURES\b" $PORTDIR returns a bunch of results. Using paludis, the issues are worked around by doing bashrc tricks.
I think the offending code here (java-pkg_ensure-test) can just be deleted, as all package managers make sure the test flag is enabled if the tests will be run. Portage and Paludis have done this for quite some time - I don't know how long Pkgcore has since Google Code doesn't seem to want to show me annotations or a per-file history, but it does now at least.
(In reply to comment #4) > I think the offending code here (java-pkg_ensure-test) can just be deleted, > as all package managers make sure the test flag is enabled if the tests will > be run. Portage and Paludis have done this for quite some time - I don't > know how long Pkgcore has since Google Code doesn't seem to want to show me > annotations or a per-file history, but it does now at least. The idea of reverting to the previous state is still floating around ;). Don't think this is realistic though. See also bug 373209. For both Portage and Paludis a reasonable amount of time has passed since, ie a user is forced to update the PM to a release containing this link on use test to use most of the current tree, thanks for trying to look it up for Pkgcore. Dropped the call java-pkg_ensure-test from java-pkg-2_pkg_setup in java-pkg-2.eclass. The pending removal of the function was announced on gentoo-dev ML.
Removed as per announcement. [1] 05 Jul 2012; Ralph Sennhauser <sera@gentoo.org> java-utils-2.eclass: Remove java-pkg_ensure-gcj and java-pkg_ensure-test. #261562 #278965 [1] http://archives.gentoo.org/gentoo-dev-announce/msg_d1a22985443720e649efe00df322a1ef.xml
