[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binary-or-shlib-defines-rpath documentation

Bas Wijnen <shevek@fmf.nl> 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
/usr/lib/arch-os-libc dir.

So please, please, please do fix (remove) the rpath in the package.


Reply to: