[Aptitude-devel] Bug#600373: [aptitude] auto-depend on debugging symbols

[Manuel A. Fernandez Montecelo]

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 <manuel.montezelo at gmail.com>