Bug#462456: lintian: Please consider testing if files in -dbg packages retain Dynamic Section entries
[ joeyh: it looks like you missed /emul in the dh_shlibdeps list, so
CCing #461339. ]
On Thu, Jan 24, 2008 at 03:33:31PM -0800, Russ Allbery wrote:
> Neil Williams <codehelp@debian.org> writes:
>
> > Package: lintian
> > Version: 1.23.42
> > Severity: wishlist
> >
> > See #462007 - I have come across a non-obvious problem in the use of
> > -dbg packages using dh_strip where, if a .install file exists for the
> > -dbg package, dh_install copies the unstripped object into the -dbg
> > build directory. When dh_strip --dbg-package=libfoo-dbg is then called,
> > it silently omits the file from the call to objcopy --only-keep-debug
> > (to prevent an objcopy error), resulting in an unstripped object file
> > being retained in the -dbg package that has a complete (and fully
> > functional) copy of the library embedded inside - as shown by the
> > presence of a full Dynamic Section under objdump -p. Without the
> > .install file, dh_strip takes care of copying the debug symbols into
> > place directly - no .install command is actually needed.
>
> Some people intentionally put debugging builds of their libraries into the
> -dbg package instead of detached debugging symbols. I think this test
> might give false positives for that case. (Or are such library builds not
> seupposed to go into /usr/lib/debug?)
As I understand this:
- detached debugging symbols go to /usr/lib/debug/$FULLPATH,
eg. /usr/lib/debug/usr/lib/libperl.so.5.8.8, where gdb will find them
- the few cases where a separate debugging build is preferred, it goes
directly under /usr/lib/debug, eg. /usr/lib/debug/libc.so.6, so it
can be used through LD_LIBRARY_PATH.
See also the GDB manual, section 15.2:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC156
This is also what dh_shlibdeps currently relies on. Quoting joeyh in #461339:
> It seems possible, though unlikely, that a debug library might be
> installed in /usr/lib/deubg/$foo/ rather than directly in
> /usr/lib/debug/. So only looking in /usr/lib/debug/*.so* or the like
> might miss some that should be processed.
> I'm pretty sure that anything in
> /usr/lib/debug/{lib,lib64,usr,bin,sbin,opt,dev}/ is going to be
> separated debug symbols, and it could just ignore those directories and
> process the rest.
I can't see anything about this in the policy, and the Developer's
Reference only talks about the detached symbol case.
I agree with Neil that a warning for packages that have the full library
object code under eg. /usr/lib/debug/usr/lib would be nice. OTOH, if
#461350 is implemented, those should also trigger the missing-dep-on-libc
error, since dh_shlibdeps doesn't look at the files.
FWIW, I can't find any usr/lib/debug subdirectories in the archive other than
the following:
sid% apt-file search -x 'usr/lib/debug/.*/' | egrep -v 'usr/lib/debug/(lib|usr|bin|emul|sbin)/'
sid%
which makes even the /usr/lib/debug/$package case look far-fetched.
Cheers,
--
Niko Tyni ntyni@debian.org
Reply to: