On Thu, Jul 13, 2006 at 09:40:23AM -0400, Charles Fry wrote: > > In almost any situation rpath is a bad thing. It is a very good idea to > > let lintian check this. A "private" library for the package is an > > exception. Of course lintian could also check and allow > > /usr/lib/$packagename without a warning. However, the rpath check is > > useful in general, because most packages don't need rpaths to run (their > > libraries are in the system library path) and shouldn't have them. > > In my situation, this isn't a "private" library. It is a library > provided by the courier-authlib package. Does that change anything?
I would think so. If the library is not in the system path, then it isn't
meant for other packages to link against it. So that means either your
package has a bug that it links to the other package's private library, or the
other package has a bug that it put a public library in a non-standard place.
Policy 10.2 says about this:
Packages containing shared libraries that may be linked to by other
packages' binaries, but which for some compelling reason can not be
installed in /usr/lib directory, may install the shared library files
in subdirectories of the /usr/lib directory, in which case they should
arrange to add that directory in /etc/ld.so.conf in the package's
post-installation script, and remove it in the package's post-removal
script.
It doesn't explicitly say, but it is clear that without a compelling reason,
the library must be installed in /usr/lib.
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
