Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Auty wrote:
> Zac Medico wrote:
> | Honestly I don't care what the existing scheme is.
>
> Fair enough, I don't maintain the code or have to deal with the
> complaints.  It seems a waste to abandon an existing scheme though.

The "scheme" is pretty worthless in my eyes. The RESTRICT variable
is quite useful for general purpose boolean flags so I see no reason
not to use it as such.

> Particularly since RESTRICT is an odd name for random boolean flags.
> Something like OPTIONS would be better, but it that can't be
> added/changed quickly.  Is there an urgent pressing need for this?
>
> |     primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS.
>
> | Looking at the above list I say it's fair game to put just about any
> | boolean flag in RESTRICT.
>
> To me, almost every item in that list has "not", "disable", "restrict"
> or some other negative in it, which lets it fit into a restriction.
> Primaryuri is the only one that looks out of place.

Again, such "schemes" are pretty worthless to me. But then, to have
a RESTRICT=live setting for ebuilds would be quite useful.

> You did sound up for a name change though, and if nothing else please do
> change it.  Our new users/developers that don't know RESTRICT is seen as
> a general purpose options flag will not find it intuitive and will
> definitely wonder what RESTRICT="live" means.  Not everybody knows the
> ebuild format intimately, and allowing people to easily pick up what's
> going on is important...

I chose "live" because I think it's easy for people to associate it
with "live ebuilds", which I believe is a common term used to refer
to ebuild that download live sources in src_unpack. What's in a name
though? I'll gladly use whatever name satisfies the most people.

> | 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.
>
> It is simpler, and as I say if there's an urgent need then go for it,
> but to me it feels like it's bolting on functionality into any space
> it'll go.  Given that some time was spent changing all the "noblah"
> flags to "blah" to fit the RESTRICT name, it's a little disappointing to
> consider shoving extra flags in it now it all makes sense.

Well, RESTRICT=live makes perfect sense to me and I see it as a
legitimate use of an existing ebuild variable that's already used
for lots of other legitimate purposes.

> This is a relatively minor point.  In the long run, if people don't like
> it, it'll get QA bugged/ironed out, if they do it'll stay, you just
> asked for thoughts...  5:)
>
> Mike  5:)

Thanks for you input. It just seems to me that you're putting some
artificial limitations on the RESTRICT variable while I see it as a
more generically useful tool to accomplish a variety of useful purposes.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkiU4QEACgkQ/ejvha5XGaOwygCfSVU2FPS9Y83JD4X/nTu5BTW+
6RIAoLsEUDuEQKNkC7B2aPKCokMyETHv
=bxM5
-----END PGP SIGNATURE-----