build paths found in binary packages/was: Re: Getting *really* close to releasing my first .deb's... What's next?
On Tue, Apr 25, 2006 at 08:06:05PM -0700, Russ Allbery wrote:
> Tyler MacDonald <tyler@yi.org> writes:
> > Russ Allbery <rra@debian.org> wrote:
>
> >> > W: libapache2-mod-bt: binary-or-shlib-defines-rpath ./usr/lib/apache2/modules/mod_bt.so /usr/local/lib
>
> >> It's not clear where this is coming from, as the Debian apxs2 should
> >> not be doing this. But I haven't looked at your package rules to see
> >> how you're building the shared library.
>
> > Debian's apxs2 clearly states:
>
> > /usr/bin/apxs2 +447: $opt .= " -rpath $CFG_LIBEXECDIR -module -avoid-version $apr_ldflags";
>
> -rpath as an option to libtool is separate and not equivalent to rpath in
> a shared library build. -rpath sometimes results in an rpath in the
> resulting object, but generally does not.
>
> However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's
> probably a problem. In general, the string "/usr/local" should not appear
> anywhere in your build for Debian packages.
I have often wondered if it would be useful to have a check (say, in
lintian ...) grepping the binary package contents for the build
directory ... assuming that the build directory is a sufficiently long
string, perhaps larger binary packages will need longer build paths,
but this doesn't seem like a real problem; /buildd/ itself is long
enough to make a random occurance in an enourmous package beyond
unlikely.
I suspect the only think preventing this from being implemented is
that too many things would be affected ..
Justin
Reply to: