[OE-core] Debug Packaging (was: rootfs_ipk, image: Add debug capture support)

[Phil Blundell]

On Mon, 2013-04-29 at 21:10 +0100, Richard Purdie wrote:
> a) Should we ditch FILES_${PN}-dbg and have it auto constructed from
>any .debug directories? This would be a rather nice automation/cleanup.
>I can't see a pressing reason not to do this.
>
> b) Consider splitting it to a -dbg package per package where there are
> debug files as per above. There are pros and cons to this and I'm torn,
> see c).
> 
> c) Consider splitting the debug source into a separate package. If we
> did do b), the question is where should the sources go?

I think (b) would definitely be desirable for the reasons I mentioned
previously.  The obvious answer to (c) is that the sources should go in
a new ${PN}-debug-source kind of package and all the ${PN}-foo-dbg
packages can recommend it.

If we do do (b) then it seems as though (a) would just fall out in the
wash so there's probably no need to consider that explicitly.

I'd also quite like to separate the sources from the debug data since I
have at least some use-cases where I want the latter installed but not
the former.

> a) A binary from package X segfaults. You want to get good gdb data for
> why. You therefore install X-dbg. X links against Y. You therefore want
> the symbols/code for Y too so you can trace into the problem which may
> be in Y.

That's true up to a point, although most people probably don't need/want
the debugging symbols for (say) glibc installed even though their
program might well link against it.  There have been some other
occasions when I've wanted to deliberately exclude the debug data for
library dependencies, most notably webkit which has such a vast amount
of debug info that GDB can take several minutes to start when it's
installed.

Also, the above does apply specifically to the "links against" case, not
necessarily for everything in RDEPENDS.  For example, if I have a
package which includes a bash script and RDEPENDS on bash, that doesn't
mean that I want my X-dbg to start dragging in bash's debug data.

> b) You want to compile against X, you install X-dev. You expect anything
> X needs to link with (e.g. through any .pc file) to also be present.

Correct.  But again, this doesn't necessarily mean installing Y-dev for
every Y that X depends on; ideally the logic wants to be a bit smarter
than that.  Nowadays you probably can get most/all of the necessary bits
from pkgconfig for the majority of packages.

> c) You want to rebuild X and hence install X-dev to ensure the build
> dependencies are present.

I think this one is a separate issue and should be handled differently,
for example by encoding the build dependencies as a Build-Depends: field
in X's control data, or by generating an extra X-build-depends output
package which just depends on all the necessary things, or (for those
people using rpm at least) generating an SRPM which contains the right
bits in its spec file.  

Note that the set of things that X needs installed in order to build
itself might well be larger than the set of things that need installing
under scenario (b) above.  

> d) There was once an idea that you could do something like install
> core-image-minimal-dev to get the equivalent of core-image-minimal with
> dev-pkgs. I think we've found better ways to do this kind of thing now?

Agreed.

p.