| 1 |
Zac Medico wrote: |
| 2 |
>> What you're missing is that only a specific subset of variables is |
| 3 |
>> cached in /usr/portage/metadata/cache. Now that you mention it, we |
| 4 |
>> could introduce a new variable called EBUILD_FLAGS and start caching |
| 5 |
>> it in new versions of portage. It wouldn't necessarily require an |
| 6 |
>> EAPI bump as long as it can safely be ignored by older versions of |
| 7 |
>> portage. |
| 8 |
|
| 9 |
Yes, that was my thinking. |
| 10 |
|
| 11 |
> Oh and by the way, I should mention that it might not be worth it to |
| 12 |
> add a whole new variable. I think RESTRICT="live-sources" is a |
| 13 |
> perfectly fine, especially considering the the existing |
| 14 |
> RESTRICT="primaryuri" value is similar in some ways, including |
| 15 |
> perceived polarity. If we do decide to add a new variable then |
| 16 |
> perhaps we should move primaryuri to the new variable as well, for |
| 17 |
> consistency. |
| 18 |
|
| 19 |
Yes, that's sort of what I am thinking. Migrate options that really do |
| 20 |
not belong in RESTRICT to another variable (and keep them in RESTRICT, |
| 21 |
of course, for backward compat for now). Then introduce new ones into |
| 22 |
whichever variable makes sense. |
| 23 |
|
| 24 |
I'm not sure the "EBUILD_" in "EBUILD_FLAGS" would be necessary |
| 25 |
(redundant?). Maybe even "OPTIONS" or "PROPERTIES" makes more sense. |
| 26 |
In fact, "FLAGS" might be a little too generic, even? Worth a short |
| 27 |
discussion. |
| 28 |
|
| 29 |
-Joe |
Archives