| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
It seems, |
| 5 |
Slightly like an abuse of the RESTRICT variable. I had thought that |
| 6 |
RESTRICT was generally for when a normal ebuild needed a feature turning |
| 7 |
off (such as mirroring, strict checking and hopefully one day ccache). |
| 8 |
5:) Overloading it with the live value doesn't seem to fit into that |
| 9 |
scheme... |
| 10 |
If there's need for a new class of ebuild information (such as a new |
| 11 |
way of categorizing ebuilds by feature), perhaps we should add an ebuild |
| 12 |
features variable specifically for the purpose? |
| 13 |
Are there many ebuilds where differentiating by inheritance is |
| 14 |
inaccurate? If so, I'd definitely suggest a new variable, if not then |
| 15 |
perhaps it's not worth the effort for the accuracy (there are eclasses |
| 16 |
for almost every type of live ebuild). If adding a new variable would |
| 17 |
require an EAPI bump (rather than simply being ignored by older versions |
| 18 |
of portage) then I'd still suggest against overloading a variable from |
| 19 |
its normal usage, especially if something better's already in the works. |
| 20 |
If we start adding bits and pieces against the naming convention for |
| 21 |
ease now, it has the potential to end up being ugly (and a problem that |
| 22 |
needs fixing) later down the line... |
| 23 |
Mike 5:) |
| 24 |
-----BEGIN PGP SIGNATURE----- |
| 25 |
Version: GnuPG v2.0.9 (GNU/Linux) |
| 26 |
|
| 27 |
iEYEARECAAYFAkiUJIUACgkQu7rWomwgFXobdwCeJyvzTtdPLAC0AoqFM8O69ajl |
| 28 |
wwQAoLiFutlJw/LjHltw2uEAkCdPHNGU |
| 29 |
=gUMq |
| 30 |
-----END PGP SIGNATURE----- |
Archives