Hello, in my overlay I need to fix a bunch of issues that crop up when
implementing EPREFIX construction in scripts due to Cygwin's
idiosyncratic, but POSIX-compliant, handling of paths beginning with
"//" (Cygwin does some arguably pathological stuff when such paths are
used).
Almost all of these stem from the careless tacking of "ROOT" onto
"EPREFIX" in bash-scripts, i.e., as in this (made-up) bash-script snippet:
${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#/}"
Thats a matter for another thread, however.
As I've been reading code like the above, I've stumbled across some bugs
and inconsistencies pertaining to relative-ROOT and I've been trying to
file bugs to get these fixed.
One such issue pertains to the case where the ROOT environment variable
is defined, but empty. Portage and most python code seem to treat this
as equivalent to ROOT="${PWD}", which is to say, that relative-root
functionality is triggered by this circumstance.
However, several app-admin and sys-devel scripts "disagree" and treat
this as equivalent to ROOT="/" (as does my example above).
So... which behavior is correct? Since I'm aware of the issue, I'd
might as well file bugs against the incorrect ones and get everything
consistent.
-gmt
