Bug 90498 – env-update not appending LD_LIBRARY_PATH ?

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Stefan Janecek 2005-04-26 07:30:07 UTC]

I just noticed that env-update does not append LD_LIBRARY_PATH variables defined in different files in /etc/env.d, but apparently replaces them instead - only the one defined in the last file shows up in /etc/profile.env.

Is this by purpose, or is this a bug?

Reproducible: Always
Steps to Reproduce:
1. cd /etc/env.d
2. echo "LD_LIBRARY_PATH=/foo1" > 98foo1
3. echo "LD_LIBRARY_PATH=/foo2" > 99foo2
4. env-update
5. grep LD_LIBRARY_PATH /etc/profile.env

Actual Results:  
export LD_LIBRARY_PATH='/foo2'

Expected Results:  
export LD_LIBRARY_PATH='/foo1:/foo2'

I am trying this on a freshly installed AMD64 system. I used the 2005.0 AMD64
CD's and stage3 to install, the last emerge --sync; emerge -u world was done
today. Installed portage version is:
sys-apps/portage-2.0.51.19

[Comment 1 Alec Warner (RETIRED) 2005-04-26 16:29:52 UTC]

Found it, portage.env_update only puts : in paths that are in special keys.

        colon_separated = [
                "ADA_INCLUDE_PATH",  "ADA_OBJECTS_PATH",
                "LDPATH",            "MANPATH",
                "PATH",              "PRELINK_PATH",
                "PRELINK_PATH_MASK", "PYTHON_PATH"
        ]
                # process PATH, CLASSPATH, LDPATH
                for myspec in specials.keys():
                        if myconfig.has_key(myspec):
                                if myspec in colon_separated:
                                        specials[myspec].extend(string.split(va$                                else:
                                        specials[myspec].append(varexpand(mycon$                                del myconfig[myspec]
                # process all other variables
                for myenv in myconfig.keys():
                        env[myenv]=varexpand(myconfig[myenv])

since LD_LIBRARY_PATH isn't in color_seperated, no colons get put in and env only picks up the latest entry, not sure if this is a bug or a feature though...portage dudes? :)

[Comment 2 Alec Warner (RETIRED) 2005-04-26 16:30:42 UTC]

Er, there are times when nano sucks, and now is one of them ;)  sorry about the $ :0

[Comment 3 SpanKY 2005-04-26 19:38:38 UTC]

i'd say use LDPATH not LD_LIBRARY_PATH ... LD_LIBRARY_PATH shouldnt really be abused in this manor ...

[Comment 4 Jason Stubbs (RETIRED) 2005-04-28 21:03:47 UTC]

This is a WONTFIX then? Or are there ebuilds in the tree that use LD_LIBRARY_PATH?

[Comment 5 SpanKY 2005-04-28 21:10:24 UTC]

i dont know of any ebuilds that do and if they exist, they're broken imo

i say this is a WONTFIX ...

[Comment 6 Jason Stubbs (RETIRED) 2005-04-28 21:23:02 UTC]

Agreed.