Bug 67467 – prelink-20040707 ebuild installs wrong contents in /etc/prelink.conf

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Jamie Lokier 2004-10-13 14:34:32 UTC]

After emerging sys-devel/prelink-20040707 for the first time, it creates an /etc/prelink.conf containing the following text:

# This config file contains a list of directories both with binaries
# and libraries prelink should consider by default.
# If a directory name is prefixed with `-l ', the directory hierarchy
# will be walked as long as filesystem boundaries are not crossed.
# If a directory name is prefixed with `-h ', symbolic links in a
# directory hierarchy are followed.
-l /bin
-l /usr/bin
-l /sbin
-l /usr/sbin
-l /usr/X11R6/bin
-l /usr/kerberos/bin
-l /usr/games
-l /usr/libexec
-l /lib
-l /usr/lib
-l /usr/X11R6/lib
-l /usr/kerberos/lib
-l /usr/X11R6/LessTif

The next time env-update it run, it is replaced by a completely different set of directories computed from the current system:

# prelink.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
-l /bin
-l /sbin
-l /usr/bin
-l /usr/sbin
-l /lib
-l /usr/lib
-h /usr/local/lib
-h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2
-h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4
-h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2
-h /usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2
-h /usr/lib/opengl/xorg-x11/lib
-h /usr/lib/MozillaFirefox
-h /usr/X11R6/lib
-h /opt/blackdown-jre-1.4.2_rc1/lib/i386/
-h /opt/blackdown-jre-1.4.2_rc1/lib/i386/server/
-h /usr/lib/libstdc++-v3/
-h /usr/local/bin
-h /opt/bin
-h /usr/i686-pc-linux-gnu/gcc-bin/3.4
-h /opt/Acrobat5

Re-merging the package from source recreates the first file, although re-merging the binary package doesn't (I don't understand why the difference).

Note the different comments at the start of each file.  The second file is computed by env-update.

The question is: why isn't the env-update-generated file created immediately after prelink is merged?  Why does it wait until the next time you run env-update, or until the next time you emerge something (which will run env-update)?

A related thing is why is the code for computing /etc/prelink.conf, including that two-line comment, duplicated in env-update.sh and portage.py?  If you look closely, the two blocks of code are _not_ equivalent: the Python one writes lines beginning with "-b", which the Bash one does not.  Likelihood of a bug there.  And, by the way, "-b" isn't documented in "man prelink".


Reproducible: Always
Steps to Reproduce:
1. emerge prelink
2. Look at /etc/prelink.conf
3. env-update
4. Look at /etc/prelink.conf
Actual Results:  
/etc/prelink.conf contains an apparently hard-coded set of paths which aren't
quite relevant.  env-update then replaces them with computed paths based on
installed software.

Expected Results:  
/etc/prelink.conf should contain the computed paths immediately after prelink is
installed.

[Comment 1 Stefan Jones (RETIRED) 2004-10-14 09:23:59 UTC]

Ok, one thing at a time!

Where about in env-update.sh is prelink.conf also generated; it must of been a change in portage regarding prelink which happened without my knowledge so it was missed when I added the "-b" lines?
( I could not find it when I looked )


I accept the -b option is not documented, I only found about it when looking at the prelink source code ( when I was about to try and start implementing a similar function)!

I used to make the ebuild not install prelink.conf at all and let portage sort it out, then someone filed a bug about no prelink.conf after installing prelink and someone else added installing the default prelink.conf.

Will see about making portage generate a prelink.conf after the install.

[Comment 2 Stefan Jones (RETIRED) 2004-10-14 11:02:01 UTC]

Ok, updated the prelink ebuild to run env-update 
(a few other ebuild do this also so I guess it is ok).

Added env-update.sh patch to the patch queue for portage (bug #63563)

Will not fix man page as I am too lazy (patches accepted, send them to prelink author also!)

[Comment 3 Jamie Lokier 2004-10-14 11:06:53 UTC]

You said:
> Where about in env-update.sh is prelink.conf also generated

The code is pretty blatant, starting from the line "# HANDLE PRELINK PATHS"
in /usr/lib/portage/bin/env-update.sh.

Running "env-update" does not call that code, it calls the code in /usr/lib/portage/pym/portage.py.

Running "env-update.sh" (/sbin/env-update.sh) doesn't appear to call that code either!

Seems quite messy and confusing to me.  Which is which?  I assume some of those files are experimental and aren't meant to be run, so they probably shouldn't be installed?

[Comment 4 Stefan Jones (RETIRED) 2004-10-22 10:25:44 UTC]

Ok, all done, prelink now does not install prelink.conf.

The lines in env-update.sh have been given a patch but it is unused so nobody cares.

I will not update man prelink. So that be it!