Re: Another dumb idea: debugging info in .deb's

[Mark Eichin <eichin@cygnus.com>]

When the issue of installing -g binaries came up "originally" [wasn't
it one of the points of contention with the FSF, back about when I
joined the project? ie. back in debian-0.9x days?] I pointed out a
tool that we used to use under 4.3BSD on Athena, called "pirts" --
just like strip, but it put the removed symbol table into a seperate
file.

The original use for pirts was to save space on VAXstation boot
floppies -- /vmunix needed to have kernel symbols for ps to work, but
it *didn't* need the kernel itself, since that was already loaded. 

However, these days gdb (I'm not sure gdb even existed back then :-)
supports a symbol-file separate from the object-file.  So you could
use pirts (or rather, objcopy --remove-section=... or something like
that, it *might* be easier to tweak objcopy or add a new command line
option like --keep-only-section=.debug) and suck all of those bits
into something else -- either a debug.tar.gz section in the .deb, or
another package altogether, whatever.

This approach still puts the load on the ftp mirrors and cdroms.  I
don't know if it's worth in all but a few cases (after all, it's
*more* important to ship buildable sources.)

Also, the approach you mention (standardizing on build/install/strip)
sounds like a reasonable extension to existing policy; a lot of
programs probably do it anyway, or at least do build/install-s, and
can just throw the -s into a make variable (or change $INSTALL to
"install --ignore-strip-arg" :-)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .