-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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...
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?
Are there many ebuilds where differentiating by inheritance is
inaccurate? If so, I'd definitely suggest a new variable, if not then
perhaps it's not worth the effort for the accuracy (there are eclasses
for almost every type of live ebuild). If adding a new variable would
require an EAPI bump (rather than simply being ignored by older versions
of portage) then I'd still suggest against overloading a variable from
its normal usage, especially if something better's already in the works.
If we start adding bits and pieces against the naming convention for
ease now, it has the potential to end up being ugly (and a problem that
needs fixing) later down the line...
Mike 5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkiUJIUACgkQu7rWomwgFXobdwCeJyvzTtdPLAC0AoqFM8O69ajl
wwQAoLiFutlJw/LjHltw2uEAkCdPHNGU
=gUMq
-----END PGP SIGNATURE-----
