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). -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
