| 1 |
On 01/04/2011 10:22 AM, Ciaran McCreesh wrote: |
| 2 |
> On Mon, 03 Jan 2011 16:40:57 +0200 |
| 3 |
> Samuli Suominen <ssuominen@g.o> wrote: |
| 4 |
>> Far as I know, S= isn't used to generate metadata cache, so it's PMS |
| 5 |
>> that need fixing for it's wording: |
| 6 |
>> |
| 7 |
>> "All ebuild-defined variables used to generate metadata cache, |
| 8 |
>> discussed in this chapter..." |
| 9 |
> |
| 10 |
> There's also: |
| 11 |
> |
| 12 |
> Global variables must only contain invariant values |
| 13 |
> (see~\ref{sec:metadata-invariance}). If a global variable's value is |
| 14 |
> invariant, it may have the value that would be generated at any |
| 15 |
> given point in the build sequence. |
| 16 |
> |
| 17 |
> which is true for all global variables, not just for metadata ones. |
| 18 |
> That paragraph's there because historically global variables have done |
| 19 |
> various different things (being re-evaluated for every phase, or just |
| 20 |
> some phases, or never, or when loaded from VDB, or ...). |
| 21 |
> |
| 22 |
|
| 23 |
I don't know the code involving package managers here, but we have |
| 24 |
eclasses like qt4-r2.eclass and kde4-meta.eclass redefining S= from |
| 25 |
src_unpack() and I haven't seen a single bug report about it. |
| 26 |
|
| 27 |
To fix the eclasses, and several ebuilds in tree to not do this for |
| 28 |
something that "might be a problem" or fix the PMS wording to match reality? |
Archives