Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

"eselect env update" behaves differently from "env-update". Path elements are
accumulated in profile.env and are not deleted, even if they are removed from
the files in env.d. The following session illustrates the problem:

# echo INFOPATH=foo >/etc/env.d/99test
# env-update; . /etc/profile
>>> Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]:foo
[O.K.]

# echo INFOPATH=bar >/etc/env.d/99test
# env-update; . /etc/profile
>>> Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]:bar
[O.K.]

# rm /etc/env.d/99test
# env-update; . /etc/profile
>>> Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]
[O.K.]

# echo INFOPATH=foo >/etc/env.d/99test
# eselect env update; . /etc/profile
Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]:foo
[O.K.]

# echo INFOPATH=bar >/etc/env.d/99test
# eselect env update; . /etc/profile
Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]:foo:bar
[This should contain "bar" only.]

# rm /etc/env.d/99test
# eselect env update; . /etc/profile
Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]:foo:bar
[Should contain neither "foo" nor "bar".]

# env-update; . /etc/profile
>>> Regenerating /etc/ld.so.cache...
# echo $INFOPATH
/usr/share/info:[...]
[O.K.]

Still the same in 1.0.9.

I observe the same. 
I tried to use "do_action env update &> /dev/null" in gnat.eselect module, but
that pulls in active enc settings (like active PATH, ADA_INCLUDE_PATH, etc)
which essentially breaks functionality of gnat.eselect module. This can be
worked around by using env-update directly inside the gnat.eselect, however
this is flagged "incorrect" in the eselect documentation (in
developer-guide.html), plus it only makes sense to use eselect's own modules
where possible.

I could provide a gnat specific extra test case, but the one above is way more
simple and represents the issue well enough (short version: add "do_action env
update &> /dev/null" to the end of do_set and do_update functions of
gnat.eselect module and try switching from e.g.
x86_64-pc-linux-gnu-gnat-gcc-4.2 to x86_64-pc-linux-gnu-gnat-gcc-4.1
(gnat-gcc-4.1.2 and gnat-gcc-4.2.0 would need to be installed) and then do ".
/etc/profile" in some shell without running env-update first and then check
PATH and ADA_INCLUDE_PATH vars. They should not contain old (but that were
active at the moment of running eselect gnat set or env update) values (4.1
when activating 4.2 or vice verse).

I also upped the severity one notch, as eselect is an important package and env
is a central its module and this is indeed a major issue for any package trying
to utilize this functionality.

George

Looks like the problem is in lib/config.bash, function load_config(). The
${key} variable misses a local declaration; so if it is not set in the config
file, then its value will happily be taken from the environment.

Attached patch should fix the problem.

Created an attachment (id=121363) [details]
Patch for eselect-1.0.9

Created an attachment (id=121365) [details]
Patch for eselect-1.0.9

Quotation marks are not neccessary here.

george: Can you confirm if the patch fixes the problem for you?

Sorry for the delay, got carried out by other stuff.
Yes, this fixes it. Thanks! Now we only need this fix to be picked up :).

George

Changed summary since the problem is not in env.eselect, but in config.bash.

Fixed as of 1.0.10