Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 431084 - eselect does not respect $ROOT
Summary: eselect does not respect $ROOT
Status: RESOLVED DUPLICATE of bug 317337
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: eselect (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo eselect Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-12 14:10 UTC by John Keeping
Modified: 2012-09-15 17:51 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to prepend $ROOT to ESELECT_DATA_PATH (eselect-ROOT.patch,410 bytes, patch)
2012-08-12 14:10 UTC, John Keeping
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Keeping 2012-08-12 14:10:41 UTC
Created attachment 321108 [details, diff]
Patch to prepend $ROOT to ESELECT_DATA_PATH

When running eselect with $ROOT set, it still finds modules in "/usr/share/eselect/modules", making it impossible to use a module inside $ROOT that is not also available in "/".

Since the ebuild configures eselect with --datadir=${EPREFIX}/usr/share, the eselect script should be prepending $ROOT to ESELECT_DATA_PATH to find the correct modules in $EROOT.
Comment 1 Ulrich Müller gentoo-dev 2012-08-13 13:24:47 UTC
ROOT is intended for specifying a target system where eselect should operate on. It's not meant to modify the path where eselect will find its own components.

For example, there would be breakage if a) versions of /usr/bin/eselect and libraries in ${ROOT}/usr/share/eselect wouldn't match, or b) no eselect was installed in ${ROOT}.
Comment 2 John Keeping 2012-08-13 19:01:32 UTC
That seems reasonable, but it means that any ebuild being emerged into a different $ROOT is not guaranteed to be able to run eselect correctly (if the relevant module is not installed in the host system).

Would it be possible to do something like this instead?

: ${ROOT=/}
: ${ESELECT_ROOT=/}
if [[ "$ROOT" != "$ESELECT_ROOT" ]]
then
    export ESELECT_ROOT=$ROOT
    exec "${ROOT}/usr/bin/$(basename $0)" "$@"
fi
Comment 3 Ulrich Müller gentoo-dev 2012-08-13 19:21:36 UTC
eselect modules that are build-time dependencies should be installed in / but not in ROOT.

But maybe you can elaborate what exact problem you are trying to solve?
Comment 4 John Keeping 2012-08-13 19:51:26 UTC
I'm trying to build (and maintain) a cross compilation image using crossdev, via the emerge wrapper that it creates.  I recently cross-emerged postgresql-server and the compilation failed because the emerge of postgresql-base had not managed to call "postgresql-config update" successfully (postgresql-config is a symlink to eselect); this was because I do not have eselect-postgresql installed in my build system, although it had been pulled into the cross-emerge target as a dependency.

I then tried to manually run "ROOT=/path/to/image eselect postgresql update", which failed because eselect could not find the postgresql module.

It may be that the answer is "you need to emerge eselect-postgresql in the build system", but since eselect is written in shell that seems like it shouldn't be necessary, especially when the necessary modules have already been pulled into the image automatically as dependencies.

If ebuilds could differentiate between "build dependencies" and "required tools" then the current eselect behaviour would be fine, but AFAIK there is no way for the cross-emerge wrapper to cause packages to be emerged into /.
Comment 5 Ulrich Müller gentoo-dev 2012-09-15 17:51:14 UTC

*** This bug has been marked as a duplicate of bug 317337 ***