Here are some more comments on the issue. I obviously am not an expert on this, I just want to see it dealt with correctly. Regardless of how this bug is resolved, the reasoning behind the decision should be formally documented somewhere for future reference (which I guess comes down to bug #378054). cheers, Charles ----- Forwarded message from Bas Wijnen <shevek@fmf.nl> ----- From: Bas Wijnen <shevek@fmf.nl> Subject: Re: binary-or-shlib-defines-rpath documentation Date: Thu, 13 Jul 2006 11:21:41 +0200 To: debian-mentors@lists.debian.org Old-Return-Path: <shevek@fmf.nl> 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. 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. About LD_LIBRARY_PATH, apart from it breaking all kinds of things, it is IMO also "owned" by the user, which means that, except in special situations, programs must not touch it. The user may want to set it to a specific value for her own reasons, and if at all possible that should result in what the user expects. If the program changes the value, the user will not understand why things don't work. And thanks for the chrpath hint! That's exactly what I was looking for to get rid of my rpaths during cross-compilation. (I didn't test if it works yet, but I suppose it will.) I think running sed on Makefiles is just too big a hack, even if it is easy. 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 ----- End forwarded message ----- -- Traveling men Know ease And speed Their shaving kits Hold what they need Burma-Shave http://burma-shave.org/jingles/1942/traveling_men
Attachment:
signature.asc
Description: Digital signature