Bug 191022

(In reply to comment #0)
> why not just remove the whole setup,
> i.e. create leave /etc/rpm/macros.prelink out of the prelink package?
Actually, I wasn't thinking when I wrote that. I suppose part of the problem is
that files may be prelinked later and thus change their MD5 value, so special
handling is required if you want subsequent "rpm -V" calls to behave as expected.

I still think that the current behaviour is rather dubious, though - a "checksum
mismatch" error is counter-intuitive when the problem is actually that the wrong
kind of files was packaged (if that's how you see it.) It would be better if
rpmbuild failed when a prelinked file was encountered. Also, the default build
setup could easily be changed so that prelink data would be silently removed -
rather like executables are normally stripped during build.

If you want rpmbuild fail when packaging prelinked files, why are you filling
a bug against prelink?
As has been said, packaging prelinked files is packager's fault.

Maybe its an rpm bug after all - I partly misinterpreted the behaviour originally.

But you are missing my point. Whether the packager is at fault really has
nothing to do with it. Reporting checksum error on installation is simply not
right, no matter how "wrong" it is to package the files contained in the package.

Also, like I have said earlier, Red Hat pretty much require me to package files
that are installed on /usr/lib or similar, and thus usually prelinked on an
RHEL4 system. See

https://www.redhat.com/f/pdf/rhel4/AppCompat.pdf

libgcc is certainly listed as the core set of libraries, so I don't understand
why you think you should package it.  See page 10 in the pdf you are
referencing.  You should of course never packaged it yourself, instead use the
system one.

The problem originally occurred not for libgcc, but libgcc_s, which is not a
"core lib" - unless I should assume it is since libgcc is listed (but how am I
supposed to know that?)

Actually, I changed my install script so that it did make that assumtion, but
this made little difference, since there are plenty of other fairly common libs
supplied with the OS that are not included in the list of core libs. This is for
instance the case for all raster image handling packages, i.e. libjpeg, libtiff etc.

Of course, I know how to deal with this situation now - if I want to package a
(non-core) system lib, I just remove the prelink info first. What I'm saying is
that I spent lots of extra time figuring this out because the error message
given was in no way helpful - and I think you should try to help other users
avoid doing the same.

And again, from a more principal viewpoint, I believe that it simply should not
be possible to create an rpm that will lead to a checksum error, using rpmbuild
alone. To me, "MD5 mismatch" means that either the package contents changed
after the rpm was built, or that the write operation failed for one of the files
during install - and I think most users will agree with me. These should be the
only cases where this particular message is given.

libgcc_s is shared version of libgcc.  You can e.g. look at the package name
that includes the library - libgcc.  The list includes names of libraries, not
prefixes of their SONAME.

Anyway, rpmbuild refusing to package prelinked packages can't be done on the
prelink side, rpmbuild needs to be changed for that.

Refusing to link prelinked packages does not solve the core problem, that
prelinking *WHILE* building can and will produce packages with incorrect
MD5 sums.

Preventing prelinking *WHILE* packages are being built is not the role of rpmbuild
either. Controlling for when prelinking runs within whatever you are calling a
build system, or verify the packaging (e.g. by installing into a chroot) for consistent
md5 sums.

(In reply to comment #7)
> Refusing to link prelinked packages does not solve the core problem, that
> prelinking *WHILE* building can and will produce packages with incorrect
> MD5 sums.
Maybe not. Is prelinking during build common? I mean, in my case, the files are
prelinked before the build, if by build you mean rpmbuild and/or the spec file's
%build script

> 
> Preventing prelinking *WHILE* packages are being built is not the role of rpmbuild
> either.
But couldn't it remove the prelink info after all other build/install steps are
done, just like it will do other kinds of manipulation of the binary files -
like stripping debug info? Or alternatively, just ignore the prelink data when
calculating the checksum for files being packaged, just like rpm verify ignores
prelink data for installed files (as I understand it.) That would of course mean
allowing installation of files with prelink info that is not consistent with the
system, but does that matter a lot? (If automatic prelink is enabled, surely the
correct info will soon be inserted anyway?)

And for what it's worth, other packaging systems I've used would actually update
prelink info on all shared objects/dynamic executables as part of the install
process.

By "build", I mean both the environment on the build system as well as the specific recipes that are run.

rpmbuild has no knowledge of what changes are involved in prelinking.

Use other packaging systems if you wish.