[gentoo-dev] relative ROOT: correct behavior when ROOT=

[gentoo-dev] relative ROOT: correct behavior when ROOT=

[Gregory M. Turner]

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

Re: [gentoo-dev] relative ROOT: correct behavior when ROOT=

[Ulrich Mueller]

>>>>> On Thu, 06 Sep 2012, Gregory M Turner wrote:

> 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#/}"

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.

Ulrich

Re: [gentoo-dev] relative ROOT: correct behavior when ROOT=

[Gregory M. Turner]

On 9/6/2012 12:55 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 06 Sep 2012, Gregory M Turner wrote:
>> 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.

Good point, but EPREFIX is empty for non-prefix gentoo.  So, I guess:

EROOT="${ROOT%/}/${EPREFIX#/}"

It's a contrived example anyhow, so it's mostly academic.

My main concern is the correct behavior when ROOT is defined, but empty 
-- I mostly included this explanation to preempt anyone inclined to ask 
"what are you trying to achieve?" :P

-gmt

Re: [gentoo-dev] relative ROOT: correct behavior when ROOT=

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/09/12 03:55 AM, Ulrich Mueller wrote:
>>>>>> On Thu, 06 Sep 2012, Gregory M Turner wrote:
> 
>> 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#/}"
> 
> 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.
> 
> Ulrich
> 

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..





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBInW8ACgkQ2ugaI38ACPA0UQD/YePPvXa5wNhdvpk656RtwNwa
+yUJKdh/cdu2d8lKCcQA/2/SI4ApNEY/uAf0VxEyRKE6jxdm9/KM6a9gWfSJ0ttn
=gJ7i
-----END PGP SIGNATURE-----

Re: [gentoo-dev] ROOT, EROOT, and EPREFIX in scripts (was: relative ROOT: correct behavior when ROOT=)

[Gregory M. Turner]

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

Re: [gentoo-dev] ROOT, EROOT, and EPREFIX in scripts

[Zac Medico]

On 09/07/2012 01:50 PM, Gregory M. Turner wrote:
> 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."

So, just submit patches to the relevant maintainers. If their code adds
an extra slash then it's easy to fix by replacing ${ROOT} with
${ROOT%/}, and then it will work correctly regardless of whether ${ROOT}
contains a trailing slash.
-- 
Thanks,
Zac