eselect wrongly treats LDPATH as a space separated variable which corrupts ld.so.conf if a setting contains a path env-update already handles env.d collection and file creation, so there's no reason for eselect to duplicate this work (not to mention get it wrong) it also produces this warning with bash-4.1: /usr/share/eselect/libs/config.bash: line 104: unset: `mtimeld_so_conf_d_*_conf': not a valid identifier
(In reply to comment #0) > eselect wrongly treats LDPATH as a space separated variable which corrupts > ld.so.conf if a setting contains a path Can you provide some example how to reproduce this? > env-update already handles env.d collection and file creation, so there's no > reason for eselect to duplicate this work (not to mention get it wrong) Right, but paludis folks would stab me if I made eselect depend on portage. ;-) > it also produces this warning with bash-4.1: > /usr/share/eselect/libs/config.bash: line 104: unset: > `mtimeld_so_conf_d_*_conf': not a valid identifier What eselect version is this?
it's pretty trivial -- create an LDPATH with a space and eselect will screw up the resulting ld.so.conf if you want to screw with stupid systems then have it be fall back code. stop doing it on portage systems.
*** Bug 298495 has been marked as a duplicate of this bug. ***
Created attachment 214524 [details, diff] Patch against eselect-1.2.8 (In reply to comment #2) > if you want to screw with stupid systems then have it be fall back code. > stop doing it on portage systems. Sounds good. I'll consider this for eselect-1.3*. Meanwhile, please try if attached patch fixes the problem. Mainly I've added a whole bunch of quotes.
patch seems to fix the ld.so.conf issue, not the warning though... I traced the warning to the need_links function, that still needs work :)
(In reply to comment #5) > patch seems to fix the ld.so.conf issue, not the warning though... You mean the following warning? (In reply to comment #0) > it also produces this warning with bash-4.1: > /usr/share/eselect/libs/config.bash: line 104: unset: > `mtimeld_so_conf_d_*_conf': not a valid identifier I cannot reproduce it. Can you attach your /var/lib/eselect/env/ld-mtimedb ?
the error did change after applying the patch, it no longer contained 'mtime' at the start of the string. I am currently at another pc, I will try to attach the requested file asap.
Hm, I don't understand that code in env.eselect: need_links && makelinks="-X" update_ldcache ${makelinks} "update_ldcache" is just a wrapper around ldconfig. But the -X option of ldconfig _suppresses_ updating of links. Is the logic really backwards here, or what am I missing?
I cannot attach the file right now (no internet on the machine in question), but I'm looking at it right now and it did contain one line mtimeld_...etc.... Removing that line and doing eselect env update (tried with and without makelinks) still produced the warning, deleting the mtime db file and doing eselect env update generated a new db file without any offending lines. However the bash warning message remains. The message is exactly this: /usr/share/eselect/libs/config.bash: line 104: unset: `ld_so_conf_d_*_conf': not a valid identifier It's caused by this file: (from most recent glibc ebuild) $ cat /etc/env.d/00glibc LDPATH="include ld.so.conf.d/*.conf" this should allow you to reproduce it.
(In reply to comment #8) > Hm, I don't understand that code in env.eselect: > > need_links && makelinks="-X" > update_ldcache ${makelinks} > > "update_ldcache" is just a wrapper around ldconfig. But the -X option of > ldconfig _suppresses_ updating of links. > > Is the logic really backwards here, or what am I missing? > In do_update() in env.eselect I see the case switch for the parameter setting makelinks variable to "-X" also when doing eselect env update makelinks...
fwiw, I use paludis on gentoo and I have sys-apps/portage installed anyway (it's just a bad idea to remove it, even per paludis website http://paludis.pioto.org/faq/howdoi.html#removeportage )... I really don't care if eselect pulls it in. I put a modified ebuild in my local repository that overwrites env.eselect with a different one from ${FILESDIR} that simply runs env-update (with or without --no-ldconfig depending on noldconfig parameter in the eselect command) and which ignores the makelinks. I guess this is the best solution; not depending on portage is useless imo. :)
(In reply to comment #10) > > Is the logic really backwards here, or what am I missing? > > In do_update() in env.eselect I see the case switch for the parameter setting > makelinks variable to "-X" also when doing eselect env update makelinks... Yes, looks like this was always wrong. Since nobody noticed, I tend to remove the "makelinks" option and the "need_links" function altogether. Unconditionally calling ldconfig without the -X option should do the right thing. (It should only matter if ldconfig gets called in the middle of a package update, namely after installation of the new version and before removal of the old. But Portage is using its internal env_update for this anyway.) (In reply to comment #11) > I put a modified ebuild in my local repository that overwrites env.eselect > with a different one from ${FILESDIR} that simply runs env-update (with or > without --no-ldconfig depending on noldconfig parameter in the eselect > command) and which ignores the makelinks. I guess this is the best solution; > not depending on portage is useless imo. :) I think we should follow Mike's suggestion and keep the existing code as fallback.
sorry, i should have realized the unset error was due to recent LDPATH changes and not bash specific issues another aspect you might want to consider is that recent glibc implements a cache itself, so there should be no need for you to do it when it's available. when you run `ldconfig --help`, look for the --ignore-aux-cache option. if it's there, then dont do the mtime checks yourself -- glibc does it better already.
New version of the module is here (I don't attach a patch since it's longer than the file): <http://sources.gentoo.org/viewcvs.py/*checkout*/eselect/trunk/modules/env.eselect?rev=747> This should also kill the "unset" warning. Please test.
The whitespace bug and the warning are fixed in eselect-1.2.9. I leave this bug open for the change to env-update.
*** Bug 299153 has been marked as a duplicate of this bug. ***
(In reply to comment #15) > I leave this bug open for the change to env-update. Fixed in SVN r757.
eselect-1.2.10 calls env-update (if it's provided by the package manager).
