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
Well, I can pull this, but IIRC, this was done on some request some time ago (it been quite a while, so I am fuzzy on particulars) to make installation of man and info pages conditional (and FEATURES was kind of *the defining* indicator). How are we supposed to test for that then and do we supposed to even care? I mean, are we supposed tom make this conditional or not?
use a USE flag - introduce a local USE flags like 'man-pages' or similar. personally i'd only make it optional if it pulls in extra dependancies and/or takes a lot of time build.
Ok, I removed optional removal of extra docs. The impact is minimal and, to start with, I didn't see such a big need in it back then :).