SSH pipe broke while running apt upgrade. What can I do about it

The most obvious difference is that aptitude provides a terminal menu interface (much like Synaptic in a terminal), whereas apt-get does not.

Considering only the command-line interfaces of each, they are quite similar, and for the most part, it really doesn't matter which one you use. Recent versions of both will track which packages were manually installed, and which were installed as dependencies (and therefore eligible for automatic removal). In fact, I believe that even more recently, the two tools were updated to actually share the same database of manually vs automatically installed packages, so cases where you install something with apt-get and then aptitude wants to uninstall it are mostly a thing of the past.

There are a few minor differences:

• aptitude will automatically remove eligible packages, whereas apt-get requires a separate command to do so
• The commands for upgrade vs. dist-upgrade have been renamed in aptitude to the probably more accurate names safe-upgrade and full-upgrade, respectively.
• aptitude actually performs the functions of not just apt-get, but also some of its companion tools, such as apt-cache and apt-mark.
• aptitude has a slightly different query syntax for searching (compared to apt-cache)
• aptitude has the why and why-not commands to tell you which manually installed packages are preventing an action that you might want to take.
• If the actions (installing, removing, updating packages) that you want to take cause conflicts, aptitude can suggest several potential resolutions. apt-get will just say "I'm sorry Dave, I can't allow you to do that."

There are other small differences, but those are the most important ones that I can think of.

In short, aptitude more properly belongs in the category with Synaptic and other higher-level package manager frontends. It just happens to also have a command-line interface that resembles apt-get.

Bonus Round: What is wajig?

Remember how I mentioned those "companion" tools like apt-cache and apt-mark? Well, there's a bunch of them, and if you use them a lot, you might not remember which ones provide which commands. wajig is one solution to that problem. It is essentially a dispatcher, a wrapper around all of those tools. It also applies sudo when necessary. When you say wajig install foo, wajig says "Ok, install is provided by apt-get and requires admin privileges," and it runs sudo apt-get install foo. When you say wajig search foo, wajig says "Ok, search is provided by apt-cache and does not require admin privileges," and it runs apt-cache search foo. If you use wajig instead of apt-get, apt-mark, apt-cache and others, then you'll never have this problem:

$ apt-get search foo
E: Invalid operation search

If you want to know what wajig is doing behind the scenes, which tools it is using to implement a particular command, it has --simulate and --teaching modes.

Two wajig commands that I often use are wajig listfiles foo and wajig whichpkg /usr/bin/foo.

I just now had to figure out an answer to this, because the last apt-get upgrade on a Debian server made it impossible to boot the most recent kernel beyond a busybox, failing to mount the zfs root partition. At least an older kernel could still boot, but was incompatible with other software. Thus the need for a rollback.

The short answer - you could use the following command:

$ apt-get -s install $(apt-history rollback | tr '\n' ' ')

if it does what you want remove the -s and run it again. Here are the steps I took to get this working properly:

1. I temporarily trimmed my /var/log/dpkg.log to leave just today's upgrade

2. I installed the tiny script apt-history from here into ~/.bashrc and ran

   $ apt-history rollback > rollback.txt
   ...
   libzfs2:amd64=0.6.4-4~wheezy 
   zfsutils:amd64=0.6.4-4~wheezy 
   zfs-initramfs:amd64=0.6.4-4~wheezy
   ...
   

3. This provides a nicely formatted list of versioned packages to roll-back to by feeding it into apt-get install. Trim this list as needed in a text editor and then run (with -s for dry-run first):

   $ apt-get -s install $(cat rollback.txt | tr '\n' ' ')
   $ apt-get install $(cat rollback.txt | tr '\n' ' ')
   

Apt will warn about the downgrades which is expected. To prevent this rollback to be overwritten by the next upgrade, the packages will need to be pinned, until the original issue is resolved. For example with: apt-mark hold zfsutils libzfs2 ...

function apt-history(){
    case "$1" in
      install)
            cat /var/log/dpkg.log | grep 'install '
            ;;
      upgrade|remove)
            cat /var/log/dpkg.log | grep $1
            ;;
      rollback)
            cat /var/log/dpkg.log | grep upgrade | \
                grep "$2" -A10000000 | \
                grep "$3" -B10000000 | \
                awk '{print $4"="$5}'
            ;;
      *)
            cat /var/log/dpkg.log
            ;;
    esac
}