[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic Debug Packages

Emilio Pozuelo Monfort <pochu27@gmail.com> writes:
> Manoj Srivastava wrote:

>>         To recap:
>>  1) packages with detached debugging symbols should be named
>>     ${package name}-${debug suffix}. As a corollary, no ordinary
>>     packages names may end in  ${debug suffix}.

> They may be automatically created. They may also be manually created (if
> they are listed in debian/control, so for complex packages where they
> need some manual work, it can be done).

Whether they're automatically or manually created is irrelevant for Debian
Policy.  Policy describes what the output should be, not what tools one
uses to get there.

I think the relevant question for Policy is whether these packages will be
listed in debian/control in the source package, in Binary in the *.dsc
file, and in Binary/Files/Checksums-* in the *.changes file.  And I don't
know the answer to those three questions from the discussion so far.

>>  3) The detached debugging symbols should be placed in a subdirectory of
>>     /usr/lib/debug, the exact path being determined by the mechanism
>>     used (either build ids or debug links can and may be used)

> Don't forget that there are other debug info, like e.g. python dbg
> extensions or mono .mdb files. Those aren't placed in /usr/lib/debug, so
> we shouldn't restrict the ddeb packages content to files in
> /usr/lib/debug.

That's a separate issue that hasn't been raised so far.  I'm surprised
that you'd want to mix this in.  I thought the whole point of this
proposal was to handle detached binary symbols in a way that's predictable
from the name of the binary package so that they could be, for instance,
automatically installed based on user request.  I thought one of the key
points of the discussion so far was that they were *not* going to take
over all of the complex variety of stuff people put into -dbg packages.

If we're also adding Python debug extensions, are we adding separate
copies of binaries built with -O0 -g?  Whole libraries built with library
debugging support?  Binaries built with more verbose trace information?
That seems like huge scope creep to me.

> 5) There may only be one ddeb per source package (if more where needed,
> we could consider it).

Why would we do this?  Surely it makes more sense to have a one-to-one
correlation between debug packages and binary packages that contain the
binaries for which we have detached debugging symbols?

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: