On Tue, 13 Nov 2007, Steve Langasek wrote:
FWIW, I don't agree that this is a fix. In one sense it makes /usr/lib "cleaner" by moving private libs into a private directory; however:
Well, I'm perfectly willing to adopt your suggestions, but I have to admit that the authors of this software do not even have an idea about proper versioning their source tarball so I do not expect a reasonable naming scheme of the libraries. Guessing from their special purpose that only serves different binaries inside the package I do not think that these libraries would have any relevance for any other project - so from a logical point of view it should go into a private directory.
- Because Debian uses ldconfig, the runtime cost of having additional libraries in the search path for other apps is negligible
There is no doubt about this.
- By moving the libs out of the default search path, you introduce the possibility that an unrelated library will have the same name in /usr/lib; this is a potential source of user confusion, as well as difficult-to-diagnose corner-case bugs
You are right here (even if I would regard chances for this problem quite low).
- When multiarch matures (or we have some other reason to move library directories around...), your package will require specific handling to update the library paths, rather than a simple change to libdir that will be handled automatically by the ld.so search path.
I admit that I have no idea about the problems that raise with multiarch and if you would regard this as an important issue, I'll probably follow your suggestion. But as I said, I'm afraid about the versioning.
So I think it's better to leave these libraries in /usr/lib instead of using rpath.
Because Josselin expressed a different opinion I will probably watch this thread and follow the final agreement. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]