On Tue, 25 Mar 2008 17:06:25 -0700, Peter Gordon wrote:
I looked into it a bit further and this does indeed seem to be a bug
on
the package itself. In 0.4.0, the -devel properly held a symlink to the
original library, but because that was moved in the 0.5.x builds, that
symlink was also removed (and thus the -devel package contains only data
files: incude headers and the pkgconfig-foo).
What would be the best solution to resolve this? Should I add a symlink
in the -devel subpackage manually? (This would resolve to within the %
libdir/nemiver directory, too, which I think was one other bug that
needed a squashing.)
Well, it would still require an rpath before linked programs would run
(and rpaths are fragile, because the library may move to a different
location). Because with a link like
%_libdir/libnemivercommon.so -> %_libdir/nemiver/libnemivercommon.so
you can -lnemivercommon at build-time, but at run-time the library is not
found as it is located outside default search path. Strictly speaking, the
package should not "Provides: libnemivercommon.so" either as long as the
lib is provided in a private path (but rpmbuild doesn't know that, and
hence you end up with automatic soname dependencies here, too).