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