Upgrading Linux Mint

I believe that the Mint distribution of Linux, which I use, has a six month release cycle. Something I learned from watching cowboy shows on TV as a kid was that you don't change horses in the middle of a river, so I skip the upgrades that occur during the school year and just do the ones that occur late spring/early summer. As a result, I only get the odd numbered versions, which is fine. I've been champing at the bit to install Mint 11 (Katya), because I want to upgrade to LyX 2.0. I've already done so on my Windows box, but the dependencies for the Linux version would have created issues with Mint 9 (Isadora). Somewhat to my surprise (I've come to expect servers and mirrors to be slammed any time a major software distribution drops), I was able to download Katya within a few days of its release. I think the upgrade on my office machine is done (subject to the inevitable tweaking here and there), and I decided to jot down my notes on the process.

Problems:

• The upgrade installs a new version of /etc/apt/sources.list.d/local-repository.list. Unfortunately, the sole line of text in it is buggered.  It should end with "binary/" but instead ends with "katya". The result is that attempts to update packages after the installation fail. Fortunately, editing the file is an easy fix. I found the information fairly quickly after a Google search, but I'm surprised it's not listed among the "Known Issues", nor prominently posted on the Mint blog, nor posted in the vicinity of the download instructions.
• Once I'd fixed the aforementioned bug and started updating packages, I got a lot of error messages about repositories. It turns out that the installation added to Synaptic's repository list a bunch of URLs for ubuntu.com and canonical.com that used "Katya" as the distribution name. The problem is that "Katya" is a Mint name, not an Ubuntu name. (I believe the corresponding Ubuntu distribution is "Natty", and in fact similar URLs containing "Natty" are also present.) So I weeded out the offending repository entries, and after that updates worked just fine.
• For some reason, I cannot reload the r-cran-vr package. First it complained that several other R packages were unfilled dependencies. Then, after I updated those packages to current versions, it said I would have to revert to earlier versions of them. Perhaps the VR package is for an earlier version of R. In any case, I don't really need it, so I'll leave it uninstalled.
• While attempting to reinstall software from a backup list of all installed packages, I kept getting an error message saying "fix broken packages first" -- even though Synaptic said there were no broken packages. This might have been related to the r-cran-vr problem. I skipped installing a bunch of packages, including r-cran-vr, and that got rid of the message.

Smooth bits:

• Once again, having /home in a separate partition paid dividends. I told the installer to remount that partition as /home with the same file system it already had (ext3), and without reformatting. Voila, all personal stuff (including pretty much all software settings) was preserved. The only problem with this approach is that eventually Linux will be using the ext9287 file system, and my home partition will still be ext3.
• Usually I have the installer reformat everything else to the latest file system, but my other main partition (/) was already ext4, so I told the installer to remount it there but not format it. Most of it gets overwritten anyway, but /opt came through intact, so a couple of (large) software packages I'd installed there survived the upgrade without needing to be reinstalled.
• I used mintBackup to create a list of installed packages. After fixing the aforementioned problems with Synaptic and doing a couple of updates of the new installation (I'm not sure why two updates were required, but no big deal), I started reloading packages from this list (again via mintBackup). Although it's possible to select all the packages on the list from known repositories and reload in one gulp, I found it more useful to upload in groups. First, it meant that if a problem were going to occur, I didn't have to wait through eight petabytes of downloads to find out. Second, it's a nice way to do a little housecleaning. In particular, I did not select any of the lib* packages. My guess is that quite a few of them were vestigial, and any that were needed would presumably be installed automatically as dependencies of the package(s) that needed them.
• The few apps I installed under Wine survived the upgrade (since they live in the home partition).

Minor Pains in the Posterior:

• I have OpenSSH and the free version of NoMachine's NX server installed on my office machine, so that I can remote desktop to it. With every upgrade, I have to remember to: install new keys for OpenSSh; convince client machines to accept the new keys (not a big deal); install new keys for the NX server; distribute the public NX key to every machine running the client; and install the new key into each client session. Life would be easier if someone came up with a script to preserve all public/private key pairs during OS upgrades.
• I use POPFile to filter spam (it runs continuously on my office PC and filters at the IMAP server, so my laptop and home machines get the benefit of the filtering). Sadly, the corpus (database) for POPFile seems to live somewhere in /usr, which means it gets clobbered by the upgrade, and so I have to retrain POPFile from scratch. Maybe next time I'll remember to track it down and back it up.
• Apparently printer definitions are not housed in the home partition. I'm having to reselect them, and it took a couple of tries to get the right driver for our networked printer.
• After the reload, I found I could not reorder application icons (for maximized and windowed applications, not applets) in the GNOME panel. Usually that is just a matter of grabbing the "button" for an application and dragging it laterally. (The corresponding functionality in Windows XP requires a third party application.) A Google search turned up similar reports on a support forum, but nothing very helpful by way of a solution. So I fooled around a bit, and at one point turned the "expand" property of the GNOME panel off (which causes it to size itself just big enough to hold its contents) and then back on (the default, which stretches it to the full width of the screen). I'm not sure if that fixed the problem (could be the post hoc ergo propter hoc fallacy), but after I did that, icon reordering returned.