Bug#555982: debian-policy: RPATH in binaries and shared libraries

[Russ Allbery]

Package: debian-policy
Version: 3.8.3.0
Severity: wishlist

Lintian has the following tag:

Tag: binary-or-shlib-defines-rpath
Severity: serious
Certainty: possible
Ref: http://wiki.debian.org/RpathIssue
Info: The binary or shared library sets RPATH. This overrides the normal
library search path, possibly interfering with local policy and causing
problems for multilib, among other issues.
.
The only time a binary or shared library in a Debian package should set
RPATH is if it is linked to private shared libraries in the same package.
In that case, place those private shared libraries in
<tt>/usr/lib/<i>package</i></tt>. Libraries used by binaries in other
packages should be placed in <tt>/lib</tt> or <tt>/usr/lib</tt> as
appropriate, with a proper SONAME, in which case RPATH is unnecessary.
.
To fix this problem, look for link lines like:
gcc test.o -o test -Wl,--rpath,/usr/local/lib
or
gcc test.o -o test -R/usr/local/lib
and remove the <tt>-Wl,--rpath</tt> or <tt>-R</tt> argument. You can also
use the chrpath utility to remove the RPATH.

and ftpmaster requires an override for this tag to allow packages into
the archive. I believe Policy is currently silent on this topic. The
normative contents of that wiki page should be turned into a Policy
proposal.

-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.30-2-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii doc-base 0.9.5 utilities to manage online documen

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Yavor Doganov]

On Thu, Nov 12, 2009 at 04:53:03PM -0800, Russ Allbery wrote:
> Tag: binary-or-shlib-defines-rpath
> Severity: serious

> and ftpmaster requires an override for this tag to allow packages into
> the archive. I believe Policy is currently silent on this topic. The
> normative contents of that wiki page should be turned into a Policy
> proposal.

The webpage currently says that RPATH is allowed for packages within
the same source package, which is how it should be.

I wonder why lintian.d.o shows warnings for some of my packages [1],
while if I manually check them there are no warnings. Is there some
discrepancy between lintian in the archive and the instance running at
lintian.d.o? (IOW, I'm asking if this package will be REJECTed now,
which would be a bogus REJECT IMO.)

[1] http://lintian.debian.org/maintainer/ya...@gnu.org.html#kazehakase

[Russ Allbery]

Yavor Doganov <ya...@gnu.org> writes:
> On Thu, Nov 12, 2009 at 04:53:03PM -0800, Russ Allbery wrote:

>> Tag: binary-or-shlib-defines-rpath
>> Severity: serious

>> and ftpmaster requires an override for this tag to allow packages into
>> the archive. I believe Policy is currently silent on this topic. The
>> normative contents of that wiki page should be turned into a Policy
>> proposal.

> The webpage currently says that RPATH is allowed for packages within
> the same source package, which is how it should be.

Yes.

> I wonder why lintian.d.o shows warnings for some of my packages [1],
> while if I manually check them there are no warnings. Is there some
> discrepancy between lintian in the archive and the instance running at
> lintian.d.o?

I'm not sure. I suspect that we didn't wipe the tag list and rebuild it
from scratch the last time that we upgraded Lintian and those tags are
old, since the lintian on lintian.debian.org also doesn't report this tag
for the current version of your package. Whatever is going on seems to be
a lintian.debian.org artifact.

> (IOW, I'm asking if this package will be REJECTed now, which would be a
> bogus REJECT IMO.)

Not so far as I can tell. Running Lintian manually on lintian.debian.org
gives your package a clean bill of health.

--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>

[Bill Allombert]

On Thu, Nov 12, 2009 at 04:53:03PM -0800, Russ Allbery wrote:

> Lintian has the following tag:
>
> Tag: binary-or-shlib-defines-rpath
> Severity: serious
>

> and ftpmaster requires an override for this tag to allow packages into
> the archive. I believe Policy is currently silent on this topic. The
> normative contents of that wiki page should be turned into a Policy
> proposal.

I would suggest a new lintian tag 'rpath-outside-usr-lib' that flags
packages with rpath pointing outside /usr/lib and /lib. This clearly
warrant a REJECT but have much less false positives than
binary-or-shlib-defines-rpath.

REJECTing pacjages before the policy is clearly laid out might lead maintainers
to add the override without much though whether the RPATH is a good idea.

Cheers,
--
Bill. <ball...@debian.org>

Imagine a large red swirl here.

[Kurt Roeckx]

On Fri, Nov 13, 2009 at 08:51:42PM +0100, Bill Allombert wrote:
> On Thu, Nov 12, 2009 at 04:53:03PM -0800, Russ Allbery wrote:
> > Lintian has the following tag:
> >
> > Tag: binary-or-shlib-defines-rpath
> > Severity: serious
> >
> > and ftpmaster requires an override for this tag to allow packages into
> > the archive. I believe Policy is currently silent on this topic. The
> > normative contents of that wiki page should be turned into a Policy
> > proposal.
>
> I would suggest a new lintian tag 'rpath-outside-usr-lib' that flags
> packages with rpath pointing outside /usr/lib and /lib. This clearly
> warrant a REJECT but have much less false positives than
> binary-or-shlib-defines-rpath.

I don't think we want an rpath to /lib/package/.

The only place rpath should point to is /usr/lib/package/
where package must be related to either the source or
binary package.

Kurt

[Vincent Danjean]

Kurt Roeckx wrote:
> On Fri, Nov 13, 2009 at 08:51:42PM +0100, Bill Allombert wrote:
>> I would suggest a new lintian tag 'rpath-outside-usr-lib' that flags
>> packages with rpath pointing outside /usr/lib and /lib. This clearly
>> warrant a REJECT but have much less false positives than
>> binary-or-shlib-defines-rpath.
>
> I don't think we want an rpath to /lib/package/.
>
> The only place rpath should point to is /usr/lib/package/
> where package must be related to either the source or
> binary package.

With multiarch support, there are other authorized paths, aren't there ?

Regards,
Vincent

--
Vincent Danjean GPG key ID 0x9D025E87 vdan...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main

[Goswin von Brederlow]

Vincent Danjean <Vincent...@ens-lyon.org> writes:

> Kurt Roeckx wrote:
>> On Fri, Nov 13, 2009 at 08:51:42PM +0100, Bill Allombert wrote:
>>> I would suggest a new lintian tag 'rpath-outside-usr-lib' that flags
>>> packages with rpath pointing outside /usr/lib and /lib. This clearly
>>> warrant a REJECT but have much less false positives than
>>> binary-or-shlib-defines-rpath.
>>
>> I don't think we want an rpath to /lib/package/.
>>
>> The only place rpath should point to is /usr/lib/package/
>> where package must be related to either the source or
>> binary package.
>
> With multiarch support, there are other authorized paths, aren't there ?
>
> Regards,
> Vincent

There should never be abn RPATH to /lib, /usrf/lib, /lib/arch-os-libc
or /usr/lib/arch-os-libc.

Isn't the only valid use of RPATH /usr/lib/<package>/...? With
multiarch maybe also /usr/lib/arch-os-libc/<package>/....

MfG
Goswin