On Fri, Jan 26, 2007 at 01:11:33AM -0500, Matthias Clasen wrote:
> 1) Why does rpm keep all those non-library DSOs as provides ? Thats
> blowing up the list of provides significantly, causing a lot of
> duplicates, and is unlikely to ever be used for ever satisfying a
> requires, unless it is in error (e.g. see libsvg.so in the list)
In
/usr/lib/rpm/find-provides
the list of files is constructed by using
solist=$(echo $filelist | grep "\\.so" | grep -v "^/lib/ld.so" | \
xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut -d: -f1)
> 2) Is rpm smart enough to disambiguate provides based on the full path,
> or is a provides for libsvg.so that lives in /usr/lib/compiz/libsvg.so
> going to be used to satisfy a requires for a shared library with the
> same name ? I guess this will rarely be a problem, since the shared
> library requirement will be against something like libsvg.so.4.
In general it is not a problem, but I think that this should be avoided.
It has been already pointed out in lists, and in numerous package
submissions (I always look for sane provides and for perl packages
there are the 'usual bogusprovides on .so files'). I just have filled a
bug against rpm:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224544
Another possible solution would be to avoid setting the SONAME for the
files that are only to be dlopened. libtool always set the soname, and it
seems to be the same for perl. Maybe this is where things should be
fixed?
--
Pat
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
