Bug#317082: Not just a dpkg bug

[Frank Lichtenheld <djpig@debian.org>]

[CCing Joey Hess. As debhelper maintainer he might want to add something
to the discussion and I don't know if he reads it already]

On Tue, Jan 24, 2006 at 04:35:54PM -0800, Steve Langasek wrote:
> If you don't handle the -l, you won't be able to resolve a full path for
> these libs.  If you have a package in this situation that's biarch and you
> have local libs for both the 32bit and the 64bit targets, how will you know
> which shlibs file to use if you don't look up the full library path and
> examine the lib for target compatibility?

Yeah, that's indeed a problem. But that isn't solved by the current
implementation either. When I think about it there is now way the
-l option (if pointing to a directory that is not known to dpkg)
changes anything about the build currently since the local shlibs
information is considered before using the ldd paths. And the ldd paths
are only used in conjunction with dpkg --search ...
The only thing it does is supressing the error "couldn't find path for
X".

So -l is usefull in one case currently:
 - If it points to an installed package that has a library which is
   listed in its shlibs file but which is not in the normal systems
   library paths (which maybe later is accessed via a wrapper that
   sets LD_LIBRARY_PATH, e.g. like /usr/bin/firefox)
(does anyone use it this way?)
This one should be easy to fix and I will do it before uploading the
current dpkg to unstable.

And we could make it usefull in one other case:
 - If there are several "local" packages that provide the same library
   let the user choose one of them.

The 32bit vs. 64bit problem should be solved by checking the library's
binary format though. I will also fix this before uploading to unstable.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/