Bugs in debuginfo packages

Roland McGrath roland at redhat.com
Fri Feb 25 01:16:07 UTC 2011


> component: CCfits (sergiopr)
>   file: CCfits-debuginfo-2.3-2.fc15.i686/usr/lib/debug/.build-id/da/7236759b8c63fab2925bd308123b9b277a238c
>    - unused debuginfo, binary is not packaged: /usr/bin/cookbook

The debuginfo is collected from the %buildroot directories.  There is an
rpmbuild check that barfs if there are any unpackaged files in there, so
that should have broken the build.  There is some macro magic to disable
that check, but Fedora spec files should not be using that (if it isn't
formally disallowed in the packaging guidelines to turn this check off,
it should be).  So I'm not sure how that could happen.

> component: Canna (tagoh)
>   file: Canna-3.7p3-31.fc15.i686/usr/bin/cannaping
>    - debuginfo missing; ELF stripped
>   file: Canna-3.7p3-31.fc15.i686/usr/sbin/cannaserver
>    - debuginfo missing; ELF stripped

It's a bug in the package build if ELF files are stripped in %install
(or before that, or built without -g).

> component: Inventor (corsepiu)
>   file: InventorXt-2.1.5-40.fc15.i686/usr/bin/SceneViewer
>    - debuginfo symlink points to another binary in another RPM package which might not be installed: Inventor-demos-2.1.5-40.fc15.i686/usr/lib/Inventor/SceneViewer

IMHO these things should not be packaged such that the same binary is
copied in two separate packages.  Here, I would think Inventor-demos would
just require InventorXt and have /usr/lib/Inventor/SceneViewer be a symlink
to ../../bin/SceneViewer.  If that's not desireable, then the right thing
to do is to have an Inventor-common subpackage that contains the binary and
have both those packages require it.  I think you should look into what the
packaging guidelines say about such cases and work on getting them to
specify that you just shouldn't copy binaries in two packages.

> --
> component: PyMca (jussilehtola)
>   file: PyMca-4.4.1-2.fc15.i686/usr/lib/python2.7/site-packages/PyMca/Object3D/Object3DCTools.so
>    - debuginfo missing; ELF is not stripped

This probably means it was compiled without -g, or perhaps that it was
stripped using (eu-)strip -g at install time.  Just like an ELF file that
was fully-stripped at install time, this is a broken package build and
should be fixed in the .spec file (or upstream makefiles, or whatever).

> component: bigloo (jjames)
>   file: bigloo-3.6a-1.fc16.i686/usr/bin/bgljfile
>    - debuginfo missing; ELF stripped

As with the Haskell code, these are binaries built by a compiler for some
other language rather than the normal GCC suite.  These compilers don't
generate DWARF.  It would be a good goal for all the compilers that produce
ELF binaries to eventually produce DWARF for them, but it is beyond the
scope of mere Fedora packaging to ensure that they do.  

These files are rightly omitted from the bigloo-debuginfo rpm.  Since
bigloo also includes shared libraries that are built from normal C, there
is rightly a bigloo-debuginfo rpm at all, to contain those.  A package that
does not build any normal C/C++/etc code at all (as is perhaps that case
with some of the ghc-* packages), should not produce a debuginfo rpm at all.


Thanks,
Roland


More information about the devel mailing list