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

Another dumb idea: debugging info in .deb's



Hi all,

I was just trying to figure out how to recompile a package so that
I could debug it - and I had a little flash.

Wouldn't it be nice if there existed .deb files that already had unstripped
binaries in them?  Then it would be unnecessary to rebuild a package
to debug it.

It can be pretty confusing sometimes to figure out how to rebuild a package
with debugging info:  many times the packages don't build "out of the box" 
- they have source-dependencies and such.  And the Makefiles are not very
consistent in how they compile/strip for debugging or not.

What would be really cool is if you could do something like:

  dpkg -i --unstripped <.deb file>

Of course, the big problem with this is that binaries with debugging info
in them are large - it's a waste of bandwidth for people to download them
if they aren't going to use them.  

But I can see a potential solution:  my upcoming "debdelta" package and 
new downloading protocol.  The client will engage in a "smart" 
conversation with the server, download portions of the target .deb file 
from the server, and rebuild a .deb file on the client that can be
installed using dpkg.  This new .deb file would not need to include
files that the user doesn't want.  So it would be trivial to exclude
documentation, or debugging info.

Actually, the initial version of "debdelta" isn't going to support doing
binary diffs (a la rsync).  So with my idea, it would only be possible to
exclude the debugging info if it was somehow stripped out of the binary 
ELF files and stored in another file.  Then an "unstrip" program could be
used to re-combine the original debugging info with the original ELF file 
if 'dpkg -i --unstripped' was run.  (This might exist already, I don't 
know)

I guess the other problem is that the debugging info will contain hard
coded locations for the source files.  I think it should be possible
to write a little utility to modify the debugging info to substitute
in wherever the user has the source installed.

We should have some standard locations for installing source packages 
(under /usr/src?).  That way, we could run the same utility against the
binaries in debian/rules to convert the developer's build location to
the standard source package location. 

My "debdelta" package isn't going to be ready for a few months, at least. 
(I'm planning on basing it on Klee's dpkgcert package certificates)

But perhaps we could move a step in this direction right away.  If we
changed the building process in debian/rules to work this way:

  1) built all binaries with debugging info
  2) install binaries into debian/tmp/....
  3) strip all the binaries under debian/tmp
  4) rest of debian/rules steps, finishing with building the package file

Now, if somebody wants a package with debugging info, they can just 
comment out step 3 in the debian/rules file - and rebuild.  

Is this a good idea?  I think it would be a large step towards making
Debian the most supportable OS around (if it isn't already).  The
quality of the bug reports would probably improve as well, if people
could debug the code more easily.

Cheers,

 - Jim





Attachment: pgpf4B2IqLUqs.pgp
Description: PGP signature


Reply to: