If I have "-sandbox" in FEATURE, portage ebuild should not attempt to compile and install sandbox. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 36831 [details, diff] don't install sandbox if FEATURES say "-sandbox"
Err.. No. You change the features down the line, and portage throws a fit when it can't find the sandbox. If this is in reference to a bsd/osx system where the sandbox can't be built currently, use 2.0.51_pre17; for macos at least, it doesn't attempt to build the sandbox.
this was for solaris build of portage...do you envision sandbox being deployed by default and not as part of FEATURES, because if not, then there is no harm in installing it conditionally because user has forced "-sandbox". unless and until somebody is purposing getting rid of FEATURES feature of the portage, your argument that FEATURES might change in future and sandbox will be used no matter what, is hollow. If its a "user-can-turnoff" feature, portage should honour it.
"unless and until somebody is purposing getting rid of FEATURES feature of the portage, your argument that FEATURES might change in future and sandbox will be used no matter what, is hollow. If its a "user-can-turnoff" feature, portage should honour it." Yes, the sandbox is a "user-can-turnoff" feature, but it's a strictly "user-can-turnoff" -runtime- feature. It *still* should be built if available. For solaris, we should do the same thing we did for macos in pre17; if the arch cannot build the sandbox (basically all bsd), don't build the sandbox. Otherwise build it. For the most part, USE flag's control compile time options, although some *do* affect how the package is initially setup for runtime; using FEATURES="-sandbox" as a USE flag is invalid (feature's *should not* be treated as a use flag), so that leaves adding a sandbox USE flag, something I'm pretty heavily against. By your logic, we should also make the building of tbz2tool optional, because -possibly- at the time of merging portage, the user wasn't building binpkgs. Sucks to be the user when later on they turn the feature on, and portage flails because it expects those binaries to exist by default. Features controls the runtime time behaviour of portage, just because the user choose to adjust the runtime behaviour of portage doesn't mean we shouldn't be building integral components of portage. Feel free to reopen the bug if you're after having the logic for disabling building sandbox on an appropriate arch/userland that -currently- cannot build the sandbox. Otherwise, again, I'm heavily opposed to this one.
OK, I think I understand your point about runtime vs. compile time feature separation now. if we were to solve this problem specifically for an os that can't build the sandbox, how do we go about that? is the fix for osx in portage now? what switch was exactly used?
yes, current portage ebuilds do not build sandbox when ARCH=macos otherwise ferringb is correct
what does it take to introduce an ARCH value 'sun'?
It takes an arch for sun. Which should be your keyword. If you can't build sandbox for sun, it would need to be added to the ebuild. There will not be a "FEATURES" or "USE" way to disable building of sandbox. If you would like me to modify the ebuild to suit Sun builds, then provide me with an ARCH or a deterministic way to establish that it is a sun machine/OS. Post a patch to this bug, reopened, or post a new bug.
