--- 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. Debian Release: squeeze/sid 991 testing ftp.uni-kl.de 990 testing security.debian.org 990 testing ftp.de.debian.org 52 experimental-snapshots qt-kde.debian.net 51 unstable ftp.uni-kl.de 51 unstable ftp.de.debian.org 51 experimental ftp.uni-kl.de 51 experimental ftp.de.debian.org 50 stable volatile.debian.org 50 stable security.debian.org 50 stable ftp.uni-kl.de 50 stable ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==============================================-+-================== libapt-pkg4.10 | libboost-iostreams1.42.0 (>= 1.42.0-1) | 1.42.0-4 libc6 (>= 2.3.4) | 2.11.2-6 libcwidget3 | 0.5.16-3 libept1 | 1.0.3+b1 libgcc1 (>= 1:4.1.1) | 1:4.4.5-2 libncursesw5 (>= 5.7+20100313) | 5.7+20100313-4 libsigc++-2.0-0c2a (>= 2.0.2) | 2.2.4.2-1 libsqlite3-0 (>= 3.7.2) | 3.7.2-1 libstdc++6 (>= 4.4.0) | 4.4.5-2 libxapian22 | 1.2.3-2 zlib1g (>= 1:1.1.4) | 1:1.2.3.4.dfsg-3 Recommends (Version) | Installed ============================================-+-=========== aptitude-doc-en | OR aptitude-doc | sensible-utils | 0.0.4 apt-xapian-index | 0.40 libparse-debianchangelog-perl | Suggests (Version) | Installed =======================-+-=========== tasksel | 2.82 debtags | 1.7.10+b1--- Output from package bug script --- aptitude 0.6.3 compiled at Aug 26 2010 19:06:44 Compiler: g++ 4.4.5 20100816 (prerelease) Compiled against: apt version 4.10.0 NCurses version 5.7 libsigc++ version: 2.2.4.2 Ept support enabled. Gtk+ support disabled. Current library versions: NCurses version: ncurses 5.7.20100313 cwidget version: 0.5.16 Apt version: 4.10.1 linux-vdso.so.1 => (0x00007ffff99f4000) libapt-pkg.so.4.10 => /usr/lib/libapt-pkg.so.4.10 (0x00000031a6e00000) libncursesw.so.5 => /lib/libncursesw.so.5 (0x0000003ead800000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x0000003ec1200000) libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x0000003eafe00000) libept.so.1 => /usr/lib/libept.so.1 (0x00000031a7200000) libxapian.so.22 => /usr/lib/libxapian.so.22 (0x0000003ead400000) libz.so.1 => /usr/lib/libz.so.1 (0x0000003eaf200000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x0000003ebe400000) libboost_iostreams.so.1.42.0 => /usr/lib/libboost_iostreams.so.1.42.0 (0x0000003eafa00000) libpthread.so.0 => /lib/libpthread.so.0 (0x0000003eaee00000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x0000003eb2600000) libm.so.6 => /lib/libm.so.6 (0x0000003eaea00000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0000003eb1600000) libc.so.6 => /lib/libc.so.6 (0x0000003eae200000) libutil.so.1 => /lib/libutil.so.1 (0x0000003ebc400000) libdl.so.2 => /lib/libdl.so.2 (0x0000003eae600000) libuuid.so.1 => /lib/libuuid.so.1 (0x0000003eb4a00000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x0000003eb5e00000) librt.so.1 => /lib/librt.so.1 (0x0000003eaf600000) /lib64/ld-linux-x86-64.so.2 (0x0000003eacc00000) Terminal: xterm :0.0 is set. /usr/bin/aptitude: /usr/bin/aptitude aptitude version information: aptitude linkage:
Hello Daniel,
2010-10-16 15:55 Daniel Herzog:
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.