The libc0.2-dbg_2.0.110-0.1.deb package is 32MB (more than a third of the total space for all the hurd-specific .deb packages). It installs over 120MB. I think this is unreasonable.
What makes it so huge is the static libraries with debugging symbols. These are particularly huge on the Hurd because of extra headers and declarations, as well as there being more code in libc on the hurd than on linux. It includes -g symbols for the libraries themselves in both the lib*_p.a libraries and the lib*_g.a libraries. I'm not entirely sure what the purpose of the libc-dbg package is, but I don't think this is necessary. Does the linux version of the libc-dbg package for glibc-2.1 include full debugging symbols for libc, and in the _p versions? I don't think it's useful to have the debugging symbols in the _p libs. Those are for profiling, not for debugging. You don't need to want to profile or debug libc itself to want the _p libs--you need them if you want to profile your program's calls into libc. For that matter, I think the _p libs should be in a separate profile package rather than the dbg package (redhat has a separate glibc-profile package). I'm not sure that it's useful to have debugging symbols for libc in the _g libs either, but maybe that's supposed to be the point of them. But perhaps the point of them is just to be surely not built with -fomit-frame-pointer, so you can get backtraces to your own code if your program crashes inside libc. Any distributed binaries with debugging symbols for libc seems kind of pointless to me. The only person who would want them is someone debugging libc, who will just build it themselves.
