dangling symlinks in rpm packages for Fedora-devel

Michael Schwendt mschwendt.tmp0701.nospam at arcor.de
Mon Oct 29 21:10:21 UTC 2007


On Mon, 29 Oct 2007 19:50:21 +0000 (UTC), Kevin Kofler wrote:

> I wrote:
> > Ouch, these are really bad. I don't understand what's going on here. These
> > are not supposed to be symlinks, they are supposed to be loadable plugins,
> > and in the F7 RPM which is built from the same specfile, they are. How they
> > get replaced with symlinks not pointing to anywhere is a mystery to me. Maybe
> > a cmake bug? Or some other toolchain component?
> 
> I just tried to rebuild the package for F8, but that doesn't fix anything (I 
> canceled the build after i386 completed with strigi-libs still containing the 
> offending symlinks). I don't understand why this happens, yet on Fedora 7 the 
> exact same spec produced a valid strigi-libs (with actual plugins, not symlinks 
> not pointing to anything).
> 
> Here's my build attempt (canceled due to invalid output on i386, the first arch 
> which completed):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=219233

Somebody needs to debug it a bit and verify whether it builds the
shared lib with the correct file name:

| cd /builddir/build/BUILD/strigi-0.5.5/fedora/src/streamanalyzer/throughplugins && /usr/bin/cmake -E cmake_symlink_library strigita_pcx.so.0.5.5 strigita_pcx.so.0 strigita_pcx.so
|

It builds a shared lib with a *.so.0 soname, but what file name? Bad
things can happen if it later creates an unversioned symlink and
possibly overwrites the built shared lib file with the symlink.

The package contains at least one other bug anyway, since a -libs pkg
has been split off without moving %post and %postun to it.




More information about the fedora-devel-list mailing list