http://archives.gentoo.org/gentoo-dev/msg_ad3f1284597e128e39f5bda062e33735.xml
The thread seems to have reached the conclusion that there's no use for this (you can for example use rename etc).
The directory moving to workaround this PMS bug is just that, a workaround. It's much cleaner to redefine the variable, so reopening ->
S is the only ebuild-defined variable mentioned in that chapter that is _not_ in metadata. And there are several eclasses that assign the variable inside of phase functions. Is there any technical reason why S must not change between phases?
Anything that's defined in global scope has been historically prone to getting reset to its global scope value (either its initial value, or one evaluated later on) between certain phases. In particular: Global variables must only contain invariant values (see~\ref{sec:metadata-invariance}). If a global variable's value is invariant, it may have the value that would be generated at any given point That matches up with the mess involved in env saving, VDB loading etc...
It's worth noting that portage's ebuild(1) command can be used execute some phases, modify the ebuild, and then execute some more additional phases. In cases when it detects that an ebuild or eclass timestamp has changed since it was last sourced, it sources the ebuild and eclasses again. This behavior could overwrite a global variable that has been set in an earlier phase.
(In reply to comment #5) > [...] it sources the ebuild and eclasses again. This behavior could overwrite > a global variable that has been set in an earlier phase. But only if the ebuild defines it _both_ in global scope and in a phase function?
(In reply to comment #6) > But only if the ebuild defines it _both_ in global scope and in a phase > function? Right.
In fact, PMS doesn't even guarantee that WORKDIR exists in global scope. ;) In section "Defined Variables" it says "legal in src_*" only.
I've checked portage behaviour for S, and it's different from the other variables defined in that chapter, in several aspects: - It is not saved in the metadata cache. - The initial value ${WORKDIR}/${P} is assigned by the package manager, not by the ebuild. - The value of S that was assigned by the ebuild is preserved only in the src_* phases. In the pkg_* phases (including pkg_setup), S may have a different value (namely it falls back to the package manager default). Especially, the statement "must not vary depending upon the ebuild phase" doesn't apply to this variable. Maybe S should be moved to the "Defined Variables" section, where also WORKDIR is described?
Created attachment 259283 [details, diff] Move S to "Defined Variables" section (In reply to comment #9) > Maybe S should be moved to the "Defined Variables" section, where also WORKDIR > is described? First attempt of a wording is attached.
(In reply to comment #10) > Created an attachment (id=259283) [details] > Move S to "Defined Variables" section I've seen no objections, so I'll apply this tomorrow.
