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 hard. 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..
signature.asc
Description: Digital signature
