-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mike Auty wrote:
> It seems,
> Slightly like an abuse of the RESTRICT variable. I had thought that
> RESTRICT was generally for when a normal ebuild needed a feature turning
> off (such as mirroring, strict checking and hopefully one day ccache).
> 5:) Overloading it with the live value doesn't seem to fit into that
> scheme...
Honestly I don't care what the existing scheme is. I just see the
RESTRICT list as a set of boolean flags that give me more
information about the ebuild than I'd have without it. Here's what
we've got now:
binchecks - Disable all QA checks for binaries.
bindist - Distribution of binary packages is restricted.
fetch - Files will not be fetched via SRC_URI.
installsources - Disable FEATURES=installsources.
mirror - Disable mirroring.
primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS.
strip - Final binaries/libraries will not be stripped.
test - Do not run src_test even if user has FEATURES=test.
userpriv - Disables FEATURES=userpriv.
Looking at the above list I say it's fair game to put just about any
boolean flag in RESTRICT.
> If there's need for a new class of ebuild information (such as a new
> way of categorizing ebuilds by feature), perhaps we should add an ebuild
> features variable specifically for the purpose?
That requires an EAPI bump, which also means that it can't be used
in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we
can use it right now in any ebuild.
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkiUNkEACgkQ/ejvha5XGaM9zACeIOK+J84QpqtFLU3jkjFUM5qv
KzcAnihwK3ugnnVAmLMcnDwG/9gld14U
=Eqiy
-----END PGP SIGNATURE-----
