Zac Medico wrote:
>> What you're missing is that only a specific subset of variables is
>> cached in /usr/portage/metadata/cache. Now that you mention it, we
>> could introduce a new variable called EBUILD_FLAGS and start caching
>> it in new versions of portage. It wouldn't necessarily require an
>> EAPI bump as long as it can safely be ignored by older versions of
>> portage.

Yes, that was my thinking.

> Oh and by the way, I should mention that it might not be worth it to
> add a whole new variable. I think RESTRICT="live-sources" is a
> perfectly fine, especially considering the the existing
> RESTRICT="primaryuri" value is similar in some ways, including
> perceived polarity. If we do decide to add a new variable then
> perhaps we should move primaryuri to the new variable as well, for
> consistency.

Yes, that's sort of what I am thinking.  Migrate options that really do
not belong in RESTRICT to another variable (and keep them in RESTRICT,
of course, for backward compat for now).  Then introduce new ones into
whichever variable makes sense.

I'm not sure the "EBUILD_" in "EBUILD_FLAGS" would be necessary
(redundant?).  Maybe even "OPTIONS" or "PROPERTIES" makes more sense.
In fact, "FLAGS" might be a little too generic, even?  Worth a short
discussion.

					-Joe