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

Richard Purdie rpurdie at rpsys.net
Mon Apr 29 20:10:08 UTC 2013


On Sat, 2013-04-27 at 17:15 -0400, Chris Larson wrote:

> On Thu, Apr 25, 2013 at 7:12 AM, Phil Blundell <pb at pbcl.net> wrote:

>         I'm not quite sure what the right way to fix (2) is.  I
>         suppose in an
>         ideal world the -dbg packages would be separated in the same
>         way the
>         parent binary packages are, but that doesn't look entirely
>         straightforward to arrange.
> 
> I had implemented something along these lines back in oe classic, when
> I was at MontaVista.  See
> http://git.openembedded.org/openembedded/tree/classes/package_dbg.bbclass for that implementation. I haven't touched it or tried using it in some time, however.

I have to admit I've been wondering if we shouldn't overhaul the -dbg
part of the system a bit. There are a few things I've been wondering
about:

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?

In the bigger picture we have various dependency chain issues as the
-dbg and -dev dependency changes are horrible. The question has always
been whether X-dbg or X-dev should be usable to pull in sensible
dependencies.

Thinking about the scenarios you might use these in:

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.

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.

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

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?

In a/b/c, the usability fail is if you try to gdb/compile, find a
dependency missing, install it and repeat this cycle several times over.

Given d) is dead, thankfully, does that let us rip some code out and
improve the dependencies?

Cheers,

Richard









More information about the Openembedded-core mailing list