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.
MfG
Goswin
Reply to: