-----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-----