RESTRICT="usersandbox" is not honored by portage... not really sure what you are after here.
IIRC, the packages fail to compile if you have FEATURES=usersandbox. userpriv on it's own is fine, and sandbox on it's own is fine.
(In reply to comment #1) > IIRC, the packages fail to compile if you have FEATURES=usersandbox. > userpriv on it's own is fine, and sandbox on it's own is fine. Well, it doesn't do anything useful, portage ignores it. :) According to changelog, this has been added for Bug 93447 in qmail-scanner. RESTRICT="userpriv" is the effective restrict there, that usersandbox thing is just redundant and silently ignored. As for qmail, this has been added for Bug 99390. It seems kinda redundant to me, the bug was about tests, those are restricted, so there's no need for additional restrictions there, or does it fail w/ userpriv as well without tests enabled? Couldn't find anything useful wrt these restricts in changelog for netqmail.
Fixed in CVS, thanks.
Still there in qmail-scanner ebuilds... ;)
20 Jul 2006; Michael Sterrett <mr_bones_@gentoo.org> qmail-scanner-1.25-r1.ebuild, qmail-scanner-2.01.ebuild: usersandbox => sandbox since usersandbox isn't a valid RESTRICT
Reopening this. Usersandbox needs to become a valid RESTRICT. qmail-scanner is a special case. The 'configure' script has always been heavily hacked by upstream, and has in the past done unsafe things - mainly around writing to the stuff used by an active install of qmail-scanner, and breaking the installed copy by doing so (and losing mail). With FEATURES='userpriv' OR FEATURES='sandbox', it compiles and works fine (and the compile is safe). FEATURES='userpriv sandbox' is the same as FEATURES='userpriv' (sandbox is not used). With FEATURES='-sandbox', it compiles, but you're vulnerable to upstream stupidity. With FEATURES='userpriv usersandbox', it fails to compile and work properly. So specifically, we want to ONLY block usersandbox. Mr_bones_: would you please revert your "usersandbox => sandbox" change ASAP to avoid qmail-scanner breaking existing systems.
*** Bug 148815 has been marked as a duplicate of this bug. ***
I remembered, that I've workarounded this problem downgrading clamav, installed qmail-scanner and after that upgrading clamav. But with latest clamav versions you cannot reemerge mail-filter/qmail-scanner.
# grep RESTRICT *.ebuild qmail-scanner-1.25-r1.ebuild:RESTRICT="userpriv" qmail-scanner-2.01.ebuild:RESTRICT="userpriv" (In reply to comment #6) > Reopening this. > Usersandbox needs to become a valid RESTRICT. Why? RESTRICT="usersandbox" will yield you either effective FEATURES='userpriv sandbox' (which translates to running as portage:portage without a sandbox) or effective FEATURES='sandbox' (sandboxed with root privs). What's the exact expected benefit from making usersandbox a valid restrict I really fail to see, you already get FEATURES='sandbox' with the current RESTRICT="userpriv". Closing this as the RESTRICT is fixed.
