Re: Automatic Debug Packages
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 06:48:47AM -0500, Manoj Srivastava wrote:
>> > The main point is probably that they shouldn't live in the main
>> > archive due to space reasons. Of course we could also filter out
>> > '*-ddeb*' or '*-dbgsym*' as long as it's not '*-dbg*', which should be
>
>> If automated debug packages should not live in the archive, why
>> should -dbg packages? As far as I can see, the issue should be based on
>> the content of the debug packages; either debug packages belong in the
>> archive, or they do not; independent of the tool chain used to assemble
>> them.
>
> Most -dbg packages *shouldn't* live in the archive, but maintainers
> keep adding them by hand anyway, and we don't have anywhere else to
> put them.
Well, right now there is nowhere to put the .ddebs either, and
they are really just .debs with a funny name too. Not very different.
> I'm not sure we would ever want to take packages that are
> referenced in the source debian/control and move them to the separate
> debug archive, I think that would play havoc with database
> consistency. It also gives us no clear way to tag files referenced in
> a .changes file as belonging to the debug archive *except* for the
> package name, and there are certainly -dbg packages that intentionally
> contain things other than detached debugging symbols and which should
> not be grouped with the ddebs.
How is a .ddeb package going to change things by the time it
gets into the archive? .ddebs will be there in the .changes file, and
the only way they are different is in the file name.
>> > dropped at some point but should live in the main archive if present
>> > as they're defined in debian/control.
>
>> They should be dropped iff the automated tools can create the
>> package; I doubt that the authors envisage 100% coverage (upstream
>> build systems are varied enough that 100% coverage would require AI
>> like capabilities).
>
> No, 100% coverage just requires package maintainers to comply with a Policy
> should from 10.1 ("By default, when a package is being built, any binaries
> should include debugging information"), making upstream build systems a
> non-issue.
OK.
> The other end is that we need a usable hook for detaching the symbols
> instead of discarding them, which is trivial for all debhelper-using
> packages, and not at all trivial for packages not using debhelper.
Why is it not trivial? I have such a hook in my pakages, and it
is not rocket science.
If you think that adding stuff like
--8<---------------cut here---------------start------------->8---
file lib_or_exec_file
objcopy --only-keep-debug lib_or_exec_file debug_file
objcopy ----add-gnu-debuglink debug_file lib_or_exec_file
strip --remove-section=.comment --remove-section=.note \
--strip-unneeded lib_file
strip --remove-section=.comment --remove-section=.note exec_file
--8<---------------cut here---------------end--------------->8---
to a rules file is "not at all trivial", then heaven help us.
manoj
--
Every man is as God made him, ay, and often worse. Miguel de Cervantes
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: