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

Re: Mandatory -dbg packages for libraries?

Steve Greenland <steveg@moregruel.net> writes:

> On 22-Apr-07, 14:39 (CDT), Neil Williams <codehelp@debian.org> wrote: 
>> I'd like to see all library source packages having a minimum of 4
>> binary packages required by Policy: the SONAME, the -dev,  the -dbg and
>> a -doc package. (Libraries for perl or other non-compiled languages
>> would be exempt from -dbg packages but not -doc.)
> 1. Rather than cluttering the archive and Packages file with -dbg
> packages that will (mostly) never be used, how about mandating a "debug"
> target in library debian/rules files, so that when someone does need the
> debug package, it's trivial to build. Since the person most likely to
> need the target is the package maintainer, there would be some incentive
> to make sure it works.

When I have needed to debug problems in the past, this has sometimes
meant over a day of rebuilding large libraries when the problem covers
several shared libraries.  I would have saved hours if I could have
just installed some prebuilt -dbg packages and run gdb.  Even more
importantly, I want to use the debug package matching the version *and
build* the user reporting the problem has.  If it's due to e.g. a
buggy header in a build dependency causing a misbuild, I would miss
this when I rebuild it.  I have had this bite me in the past.

I would personally support the requirement for every binary library
package to have a separate -dbg package containing the debug symbols.
Even if they don't get regularly used, they are worth it for when
things go wrong.  We can then just ask the user to install libfoo-dbg
and send us a backtrace, whatever the package or library.  For big
and/or popular applications, it would also be nice to have -dbg
symbols for them as well.

If there are concerns over archive size, why don't we drop all static
.a libraries at the same time.  Given that in Debian we typically
always link dynamically, is there a need for .a libraries in all but a
handful of cases?

> 2. Why a seperate -doc? API docs should be part of the -dev package. I'm
> going to guess that for *most* libraries, the docs are a trivial part of
> the size of the -dev package.

For libraries using doxygen, it can generate megabytes of
documentation, even for small libraries if you enable all the call
graphs and things.  Unless I'm actually developing using a particular
library directly, I don't want disk space wasted by its docs.  It also
means less to download when autobuilding stuff.

> For those with significant documentation, sure, a seperate -doc
> makes sense, just as we do now.



  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: pgpQhLIteRHSK.pgp
Description: PGP signature

Reply to: