Quoting zlinw@mcmedia.com.au (zlinw@mcmedia.com.au):
One of my systems has had Debian 7.x (AMD64) installed from 3 DVD's and subsequently it has been upgraded over the internet to testing a number of times. The last of these upgrades was sometime back (6 months or so). This was upgraded to 8.1 yesterday. Unfortunately its left the package system in a poor state. Note, previous experience doing this shows Debian's package system does not like this combination (install from cd/dvd and update via the internet) to go beyond the next version number.
Aptitude wants to remove a large number of packages like blender, gimp, exiv2, the list going on and on. dselect how ever is much more on the ball, it only wanting to remove imagemagik and graphicsmagik. Apt does not appear to know what its doing, for instance it wishs to remove blender for 2 unmet dependencies. Curiously dselect, dpkg AND looking in the /var/lib/dpkg/info directory shows these dependcies ARE on the system.
It's distinctly possible apt is not getting on well with a system thats been instaled from DVD's.
You really should not use both aptitude and apt-get, as they will in that case store separate 'hinting' records, i.e., they don't share that data. Thus, it's better to pick one tool or the other, rather than using both. I'm guessing the attraction of aptitude for you is its full-screen ncurses mode, reminiscent of dselect's. The apt suite (apt-get, apt-cache, etc.) admittedly has nothing quite like that, which is fine for some of us (e.g., yr. present correspondent) but not others. Also, the apt tools are faster and lighter-weight. In general I concur with the people who've been advising you to eschew dselect on grounds of it being ancient/unmaintained/deprecated/whatever, but FWIW, if you really like the tool and want to keep using it, many of its drawbacks can be eliminated by selecting the apt 'method' within dselect. (IIRC, that still leaves dselect handling dependency resolution, which I personally would consider a deal-breaker. Disclaimer: I don't think I've actually used dselect since Debian 3.0 'woody' days, so please cross-check anything I say about it at this very late date.) So, anyway, I'd recommend picking either apt-get or aptitude, making a note of the packages your preferred tool wants to remove, letting it remove them, and then reinstalling those when it's done. Warning: On the Debian 'testing' branch, at any given time, some packages just aren't installable because of missing dependencies, generally required libs for which the necessary version hasn't yet cleared package quarantine from the 'unstable' repos, whereas the package that requires the new lib has cleared quarantine. This is an inherent consequence of tracking 'testing', and you should follow 'testing' only if you're prepared to deal with that problem. The usual suspects are GNOME and KDE4 packages, as those are the worst dependency hairballs. I _have_ successfully deployed as a workaround adding to the /etc/apt/sources.list[.d/*] files lines for the 'unstable' branch _with_ pin-priority for those sources set to 50 (way below the default priority of 100), ensuring that the 'unstable' sources are never consulted _by default_. The idea is that, if package foo is currently uninstallable on 'testing' because the new version of lib bar hasn't yet cleared quarantine, you can specify installation of _just_ foo and its immediate dependencies from the 'unstable' branch without moving the rest of your system off stable: # apt-get -t unstable install foo Don't act on any of this advice without reliable and fresh backups. ;->