On 9/6/2012 5:56 AM, Ian Stakenvicius wrote:
On 06/09/12 03:55 AM, Ulrich Mueller wrote:
On Thu, 06 Sep 2012, Gregory M Turner wrote:
${ROOT:=/} EPREFIX="@GENTOO_PORTAGE_EPREFIX@"
EROOT="${ROOT}${EPREFIX}"
When ROOT is undefined or empty, this script will assign "//foo"
to EROOT and bad things will happen in Cygwin.
Several correct-ish solutions exist, i.e., in the above we could
change the concatenation statement to read:
EROOT="${ROOT}${EPREFIX#/}"
I'd rather do it the other way around: EROOT=${ROOT%/}${EPREFIX}
Reason: EPREFIX is guaranteed to start with a slash, whereas for
ROOT I wouldn't be so sure that it always ends with one.
Not to mention that `man 5 ebuild` specifically defines EROOT to be
"${ROOT%/}${EPREFIX}/" already , so all that's needed is the removal
of the final '/' if I'm reading this correctly..
Yeah, that trailing slash is kinda sneaky because it saves the day in
the decidedly non-pathological "normal" case where ROOT is undefined and
EPREFIX is empty.
That's another kind-of gross inconsistency that crops up with some
regularity. In portage python code, EROOT does, indeed, always end in a
slash, just as man 5 ebuild specifies.
But in some places, i.e., in eselect, EROOT does not to end in a slash,
or even has trailing slashes stripped from it. In the case of eselect
(which I'm just using as an example), this "quirk" has a bunch of
consumers: the eselect plugins use code like:
foo="${EROOT}"/usr/bar
which, if it were in an ebuild, would instead be properly written as:
foo="${EROOT}"usr/bar
Indeed, most ebuilds do this correctly although occasionally I've seen
exceptions. My overlay is for Prefix so it "lucks out" if ebuild
authors forget this and add the slash; but if/when non-prefix cygwin
support is resuscitated in Gentoo, all of those extra slashes need to be
fixed "or else."
Anyhow, my point is that this tendency to effectively standardize subtly
inconsistent usage of EROOT is pretty !@#$&*ing gross.
I'd meant to save this "argument" for a separate thread, since a) now my
original question isn't likely to get answered and b) I might seem to be
bitching and moaning, as I don't, yet, have any patches to share -- but
IMO if a bunch of scripts are going to call a variable "EROOT" in
Gentoo, it seems like a no-brainer that the variable should have the
same meaning in all of them.
This isn't the case right now, and has led to some real-world problems,
so my feeling is that there ought to be some official documentation
explaining in clear, simple terms:
o what is the idea/point behind ROOT, EPREFIX and EROOT
o where these variables (legitimately) come from, in other words,
when can a user or developer inject them, and when should he
or she be retrieving them from portage (i.e.: ebuilds).
o the circumstances under which these variables must be changed
in-flight, especially, for relative-ROOT activation
o how to properly cook these variables when writing a script
that will interact with portage (specified in a way that does
the right thing for invokers and invokees, alike).
o any EAPI interactions with the above (don't think we have any
yet(?) but some recent proposals seem poised to change this).
Once we have that right, it's just a matter of changing all the scripts
to do what the official documentation says -- if we can't, then
obviously it's back to the drawing board to fix the specification,
lather, rinse, repeat.
I'd be happy to do this myself but I'm not sure I know all the correct
answers to the above questions (hence my original thread topic, for
example), nor am I 100% sure what the correct place would be to document
this (probably the dev manual or the wiki?)
An alternative to documenting and synchronizing code would be to build a
source-able library script to automatically handle this type of thing.
Maybe that's overkill, or maybe it's brilliant, I'd be interested to
hear people's opinions. I'm pretty sure we are just talking about a
very few lines of simple code so my gut instinct is that it's overkill
-- but if we expect things to get more complicated in the future, then
centralizing the code, now, could save us some hassles, down the line.
tl;dr: we should standardize EROOT, but how?
-gmt
