Control: tags -1 + wontfix Control: retitle -1 aptitude: auto-depend on debugging symbols (install/remove -dbg package automatically, along with binaries)
Hello Daniel, 2010-10-16 15:55 Daniel Herzog:
Package: aptitude Version: 0.6.3-3.1 Severity: wishlist --- Please enter the report below this line. --- I would like like to be able to have aptitude automatically install debugging symbols (where they are available) as if they were dependencies. This way, no manually installed debugging symbols will be needed, thus they will be removed whenever the package they belong to is being removed, too. The result aimed at is to effectively be able to have a Debian system which mostly behaves as if the binaries weren't stripped to begin with, thereby facilitating development. Manual installation of the -dbg packages is not the same thing. This is going to be especially usefull, once automatical generation of -dbg packages is implemented.
I don't think that this is a good idea. Take for example only a few of the tools that can be installed in a typical desktop (sample taken from large packages, of course): chromium-dbg [1], ffmpeg-dbg [2], gimp-dbg [3], kate-dbg [4], kwin-dbg [5], libwebkit2gtk-4.0-37-dbg [6] (by epiphany-browser), and libreoffice-dbg [7]. With just these, the download size of the .debs probably exceeds that of the rest of the system, and the unpacked size in the disk of these is also probably more than the rest of the system. Also, if multi-arch is enabled and the package installed, it would install the -dbg as well for the multi-arch version, doubling the figures. So if users enable this casually and "just in case", they risk running out of space in existing system (fair enough -- it's their choice, but then again I assume that some complaints and bug reports will come back to use asking to improve the situation in some ways). But more importantly, if a significant fraction of users enable this, and those users use unstable/testing (there is a likely correlation), this could have serious consequences in the load and bandwith of the web of mirrors. So I think that yes, it could be useful in some cases to have this, but there are also some dangers, specially to the Debian infrastructure, and given the size of the packages it can get out of control pretty quickly, at which point we couldn't do much to "undo it". Apart from that, it would need quite a serious effort to think about it, design and implement this properly and deal with all corner cases; and given the shortage of time I think that it's better to spend the available one elsewhere. And given that 5 years went by already, this is not going to be implemented soon in anycase. So I am leaving it open for the time being, but marking it as +wontfix. [1] Compressed Size: 652 M, Uncompressed Size: 695 M The binary itself is many times smaller: Compressed Size: 37.6 M, Uncompressed Size: 145 M [2] Compressed Size: 36.9 M, Uncompressed Size: 43.5 M [3] Compressed Size: 12.3 M, Uncompressed Size: 55.3 M [4] Compressed Size: 21.2 M, Uncompressed Size: 22.5 M [5] Compressed Size: 49.3 M, Uncompressed Size: 52.9 M [6] Compressed Size: 1,128 M, Uncompressed Size: 4,971 M [7] Compressed Size: 675 M, Uncompressed Size: 3,167 M Cheers. -- Manuel A. Fernandez Montecelo <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
