A couple of ebuilds currently use FEATURES to determine if userpriv is in use. They should either be changed to use a different mechanism to detect root or non-root privs (with bugs filed) or this use of FEATURES should be allowed by the PMS. A couple of ebuilds check for noinfo, noman, ccache, distcc and more. The same thing applies here: either this needs to be allowed by PMS or it needs bugs filed for the ebuilds.
FEATURES is considered a package manager configuration issue, and so beyond the scope of the specification and not usable by ebuilds. Ebuilds that do use it can be fixed in due course.
some are package manager specific, but some are not userpriv for example is documented in the PMS so checking it via FEATURES is valid
RESTRICT != FEATURES. FEATURES is a package manager configuration thing and ebuilds shouldn't be using it. Ebuild behaviour shouldn't depend upon anything in FEATURES.
(In reply to comment #3) > RESTRICT != FEATURES. > > FEATURES is a package manager configuration thing and ebuilds shouldn't be > using it. Ebuild behaviour shouldn't depend upon anything in FEATURES. > So we fix it for EAPI=1 then unless you have some idea for tests that fail with root. I have for example seen one case where it tests opening some files which of course always succeeds as root so the test is marked as failing. We could of course decide that all these should switch to RESTRICT=test but that would a lost in functionality.
The particular dodgy tests, and only those tests, should be disabled.
(In reply to comment #5) > The particular dodgy tests, and only those tests, should be disabled. And if it is 99% of the tests? MySQL for example heavily relies on being run with userpriv.
(In reply to comment #6) > (In reply to comment #5) > > The particular dodgy tests, and only those tests, should be disabled. > > And if it is 99% of the tests? MySQL for example heavily relies on being run > with userpriv. Yup, completely a no-go for mysql.
MySQL uses [[ $UID -eq 0 ]] instead of testing FEATURES for userpriv now.
Ok, we need a different solution than [[ $UID -eq 0 ]], because pkg_setup is always run as root. I'm strongly inclined to go BACK to testing FEATURES for userpriv, and to hell with Paludis/PMS.
(In reply to comment #9) > Ok, we need a different solution than [[ $UID -eq 0 ]], because pkg_setup is > always run as root. Doing it in pkg_setup breaks binpkgs anyway. You could always move the check to src_unpack... it's a bit hacky, but it should solve both problems nicely.
I agree, it would be crazy. But can't you have root's UID != 0? Then what?
(In reply to comment #11) > I agree, it would be crazy. But can't you have root's UID != 0? Then what? It's UID 0 that's special, not the username 'root'.
(In reply to comment #12) > (In reply to comment #11) > > I agree, it would be crazy. But can't you have root's UID != 0? Then what? > > It's UID 0 that's special, not the username 'root'. > ah, thx. I was missing that bit of info.
