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

Re: Mandatory -dbg packages for libraries?

Neil Williams wrote:
> > > Certain packages have already had bug reports requesting a -dbg
> > > package.
> >
> > I'd rather see some offline debug-symbol infrastructure for all
> > packages implemented, so that you can download the debug symbols when
> > you need them.
> But the -dbg package only depends on the same version of the library -
> the library won't depend on the -dbg so those who need the -dbg are the
> only ones who would download and install them.

Each time this has come up before, the concern has been that adding -dbg
versions of every binary package would greatly inflate the size of the
archive, and nearly double the total number of packages, with associated
scalability problems.

Even with separated debugging symbols, -dbg packages are frequently
larger than the package they provide debugging symbols for. See for
example xserver-xorg-core-dbg. Looking through the 227 lib*-dbg
packages, I found few contain separated debugging symbols, except for
packages maintained by the xorg team[1]. I'm not sure if this is due
many people still not knowing about separated debugging symbols, or due
to technical reasons. For example, is there a tecnical reason why
libc6-dbg does not contain separated debugging symbols?

Anyway, doubling the size of the archive is less of an issue than it
might have been in the past, since we've done the archive split, and
since ftp-master has 1.4 Terabytes of disk with half that unused, but
it is still a concern, for mirrors, number of DVDs, etc.

Scalability issues with the number of packages have also been reduced in
some areas. apt no longer has to download the while Packages files on
each update, so it wouldn't take 2x the bandwidth to add -dbg packages
for every package to the Packages files. There would still be
significant impact in apt's memory usage, in the disk space used to
store the Packages files, in the UIs that have to somehow present or
hide all these -dbg packages, etc.

I've considered before trying to set up a separate, parallel archive
that would only hold the -dbg packages, but implementing that without
initially using the Debian infrastructure would be tough, and my
experiences with setting up[2]/maintaining the separate udeb section of
the archive is that it adds a lot of complexity.

Someone made a very good point that it's often and increasingly painful to
rebuild debugging versions for the whole library chain of a binary.
OTOH, rebuilding a debug version of the binary itself is not especially

So while I'd love to have a way to have -dbg packages available for
every binary, I actually am happy with this proposal to do it for only
every library (plus whatever other binaries really need it). And it's a
direction we're already moving in, with, as I mentioned, 227 lib*-dbg
packages already in the archive. That's more than 10% of all our
libraries already done[3].

So I suggest that we take this as an existing practice, document it as a
"should" in policy for now, document *how* to do separated debugging
symbols in the developers reference (which does not currently seem to
mention it at all), and go add -dbg versions of our library packages.

see shy jo, doing so for aalib now

[1] Who are doing a really nice job on their -dbg packages.
[2] Actually, the ftp-masters did all the real setup work.
[3] Conversely, there are only 62 -dbg packages for non-libraries..

Attachment: signature.asc
Description: Digital signature

Reply to: