On Tue, Jun 09, 2009 at 08:28:27PM +0100, Adam D. Barratt wrote:
> On Tue, 2009-06-09 at 20:45 +0200, Filippo Giunchedi wrote:
> > perhaps I'm missing something obvious but check this:
> >
> > $ lintian bluez_4.40-3_amd64.deb
> > $ lintian bluez-compat_4.40-3_amd64.deb
> > W: bluez-compat: binary-or-shlib-defines-rpath ./usr/bin/dund /usr/lib
> > W: bluez-compat: binary-or-shlib-defines-rpath ./usr/bin/hidd /usr/lib
> > W: bluez-compat: binary-or-shlib-defines-rpath ./usr/bin/pand /usr/lib
> > $ dpkg-deb -x bluez_4.40-3_amd64.deb /tmp/a
> > $ dpkg-deb -x bluez-compat_4.40-3_amd64.deb /tmp/b
> > $ find /tmp/{a,b}/usr/bin -type f | xargs chrpath
> > /tmp/a/usr/bin/dfutool: RPATH=/usr/lib
> [...]
> > /tmp/b/usr/bin/hidd: RPATH=/usr/lib
> [...]
> > shouldn't lintian report rpath even in bluez?
>
> The difference between the two packages is that bluez ships /usr/lib/ as
> part of the package (as it ships files contained therein), whereas
> bluez-compat does not. The rpaths in bluez are therefore being skipped
> due to the exception introduced as a fix for #480636, allowing rpath to
> point to a directory shipped in the package.
agreed, would permitting only directories with actual files be a sensible
tradeoff?
in any case, is there a level of detail where the check actually emits some
"rpath set, but ignoring" ?
thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net - 0x6B79D401
Man was made at the end of the week's work when God was tired.
-- Mark Twain
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
