Prelink success story :)

[Jakub Jelinek]

On Wed, Feb 25, 2004 at 03:58:24PM +0000, Keith G. Robertson-Turner wrote:
> Guess I've been lucky, but I never really suffered much from the various
> prelink related problems that have been reported.
> 
> A total of 2 applications (out of 1603 packages) were bØrked by prelink
> on my system, since FC1 was released, namely k3b and kdepim (in fact they
> still get bØrked even now by prelink).

Even 2 packages being borked by prelink is something I don't like to see.
But the question is if it isn't a bug in the applications themselves or
libraries they are using.
Recently I received a bunch of bugreports which turned out to be e.g. memory
management bugs in the application, which just happened to work without
prelinking with pure luck and prelinking changed the memory layout slightly
and suddenly things started crashing.
Can you run the apps under efence or valgrind to see if they don't have
these kind of bugs?  If they don't, then I'd be very much interested in
reproduceable testcase
( tar cjhf `ldd the_binary | awk '{ print $3 }'` the_binary the_binary_unprelinked
and steps how to get the crash with the_binary while it works with
the_binary_unprelinked).

> I got prelink-0.3.0-21 from (Fedora devel) rawhide, but it needs SELinux.

It needs SELinux only for execstack (prelink is statically linked and thus
has libselinux.a linked into it) and only if it is run on a SELinux capable
distribution, so if you don't need the execstack program (most probably
you don't), you can safely --nodeps.

> 1) ... Is Jakub Jelinek really the *only* guy working on this?

For now yes.  Of course patches are welcome, if there are enough I might
even put it into CVS.

> 2) ... Other than in the SRPM, where's the source Luke :)
> prelink-20040216.tar.bz2 is missing from people.redhat.com/jakub/prelink

I'm usually lazy, so most often it is just the SRPM.  From time to time
I don't forget and copy it to the above URL.

> 3) ... Why was macros.prelink hard coded into the spec as a text block,
> rather than as a SourceX file?

macros.prelink is rpm specific.  The prelink sources attempt to be
independent from any package management system.

> 4) ... Why isn't there a logrotate file to accompany the included log
> file, and come to that, why *package* a log file? Or am I missing
> something obvious?

The log file is %ghost and was added only because others complained no
package owns the file.  Logrotate is not used because I don't think it
is very much interesting to look at older logs, but you can try to
convince me otherwise ;)

> Other minor (rpmlint) observations:
> 
> Use of "Copyright" instead of "License"

Changed (although, I'll need to tweak my other packages like gcc, glibc,
binutils, ...).

> Weird 555 and 444 perms

Where?
rpm -qplv SRPMS/prelink-0.3.0-21.src.rpm x86_64/prelink-0.3.0-21.x86_64.rpm
-rw-r--r--    1 root    root           338790 Feb 16 07:34 prelink-20040216.tar.bz2
-rw-r--r--    1 root    root              738 Nov 18 06:42 prelink.conf
-rw-rw-r--    1 root    root             1455 Oct 27 14:32 prelink.cron
-rw-r--r--    1 root    root            17323 Feb 16 07:47 prelink.spec
-rw-rw-r--    1 root    root              818 Sep 14 05:44 prelink.sysconfig
-rwxr-xr-x    1 root    root             1455 Oct 27 14:32 /etc/cron.daily/prelink
-rw-r--r--    1 root    root              738 Nov 18 06:42 /etc/prelink.conf
-rw-r--r--    1 root    root              297 Feb 16 09:23 /etc/rpm/macros.prelink
-rw-r--r--    1 root    root              818 Sep 14 05:44 /etc/sysconfig/prelink
-rwxr-xr-x    1 root    root           147456 Feb 16 09:23 /usr/bin/execstack
-rwxr-xr-x    1 root    root           874720 Feb 16 09:23 /usr/sbin/prelink
-rw-r--r--    1 root    root             1204 Feb 16 09:23 /usr/share/man/man8/execstack.8.gz
-rw-r--r--    1 root    root             3473 Feb 16 09:23 /usr/share/man/man8/prelink.8.gz

> Ghost-without-post errors

Why is that an error?  The files are %config missingok.

> Use of "/etc" instead of %{_sysconfdir}

Changed.

> Use of %{buildroot} instead of $RPM_BUILD_ROOT (although that seems to be
> a point of contention these days, personally I prefer %{buildroot}, since
> it is more consistent with the other spec conventions.

This is on purpose, %{buildroot} is more readable.

> Anyway, I'm just really pleased to have blacklist support in prelink
> finally, which I guess leads me to one final question ... why hasn't this
> version been officially released yet? (Although maybe I've answered this

By officially releasing you mean what exactly?  Any release of prelink I do
can be considered official...

	Jakub