Re: binary-or-shlib-defines-rpath documentation
Bas Wijnen <firstname.lastname@example.org> writes:
> On Wed, Jul 12, 2006 at 05:32:12PM -0400, Charles Fry wrote:
>> > > > Depends. Does it actually fix the warning?
>> > >
>> > > Yes, but it also broke my binary, which can no longer find the needed
>> > > library. Any suggestions? Is rpath okay in this case? The needed library
>> > > is coming from /usr/lib/courier-authlib.
>> > In this case, I believe it is correct. rpath is bad when it points to
>> > a system dir such as /usr/lib. Is good when it points to an
>> > application private dir.
>> So is the lintian test wrong? Should it only be checking for rpaths that
>> aren't system directories?
> No, the lintian test is not wrong. However, an override is in order in this
> situation, IMO.
Even (or especially) an rpath that is a system directory is wrong. You
won't notice any problems on a normal system but when you try to use
the binary e.g. on a SuSe system with libs in ~/libs it fails
miserably. It is a big drawback for interoperability.
Secondly such packages nearly always will use /usr/lib64 as rpath on
amd64 while libraries are in /usr/lib. This confuses dpkg-shlibdeps
(workaround exists in etch/sid now) into not finding the *.shlibs
files and missing Depends entries.
Thirdly with multiarch all libraries are moving into new places and
any rpathed binaries will fail to find them in the new
So please, please, please do fix (remove) the rpath in the package.