Upgrading an existing Ubuntu : the kill-your-desktop machine !

by Ploum on 2009-02-04

If you look in the mirror and see how was your computing world a few years ago, you would probably not believe it. Back in 2002, there was no Ubuntu, no OpenSuse, no Fedora and Mandriva was called Mandrake. Installing a Debian was a geekish thing that didn’t detected anything automatically (not even the screen nor the mouse). Installing a printer was a matter of playing with the cups command line, Gnome was still 1.X (at least in Debian) and we didn’t even thought about installing a webcam. In 2004 came Ubuntu and it’s share of nude people. Connecting to a Wifi network required hours of command line knowledge and it was brown.

It’s wonderful to see from how far we come and that, now, we can spend time to polish stuffs. And one big point that need polish is certainly the Ubuntu upgrade process.

In theory, the apt-get update/upgrade works well with the update-manager interface.

Lemma 1

From my experience, people have a lot of difficulties to tell the difference between a normal upgrade and a full upgrade (dist-upgrade). They don’t really grasp the concept of « new version ». I don’t believe users have to learn that concept but it has some consequences

Problem 1

Upgrading is way too slow. It takes ages. Why could it not start to upgrade a part of the system as soon as some packages are already downloaded ? Also, there’s very few feedback that the system is actually doing something.

Problem 2

You cannot just let your system upgrading because it asks you some question and will wait for the response. Why cannot those questions be asked before beginning the upgrade ? Oh and, by the way, none of those questions are understandable by normal users. And most questions are about config files I never touched.

Problem 3

Upgrade just crash once in a while. It knows that a simple apt-get -f install will solve the system but insists that you do it yourself. Also, sometimes it looks like it is finished but launching apt-get dist-upgrade once again shows more than 300 non upgraded packages with are in an unknown state. In the end, upgrading quickly become a serie of apt-get dist-upgrade, apt-get -f install, apt-get dist-upgrade, apt-get -f install until no more packages left.

Problem 4

Shutting off the computer in the middle of the upgrade process leaves it, most of the time, in an awful state and you can be sure that X doesn’t work.

Problem 5

After upgrading, a lot of old crap stays on the computer. You have to run apt-get autoremove –purge deborphan multiple times but it’s not really enough because the program is not detected by deborphan. Just remember all the old cupsys stuffs, gnome-volume-manager, things like that. On most upgraded computers, they are still there !

Consequence 1

Problem 1,2 and 5 imply that geeks will just reinstall their Ubuntu by formatting the / partition. On my computer, installing a new Ubuntu and the packages I need take approximately 1 hour. Upgrading my whole system takes more than 4 hours ! But, come on, we are not Windows. Do we really need to reinstall every 6 months ?

Consequence 2

This one is a lot more important to my opinion. I’ve installed Ubuntu to a lot of « normal » users. Lemma 1 and Problem 2 or 3 lead them to just think the computer has finished or has a problem. So what will you do if you might have a problem ? Reboot of course, hitting problem 4 in the face !

They will then just discover a black screen with blinking lines of text. Their conclusion is simple enough : the computer is broken and it is because of the upgrade. Technically advanced users not familiar with Ubuntu will try to change X.org config to « repair » the broken X11, never thinking that apt-get dist-upgrade will solve their problem.

That a very bad point for Ubuntu but, more, it has a very important impact : normal users will avoid upgrading at all cost ! The vast majority of normal users I know don’t upgrade anymore. They ask me to do it. I’m not speaking about « dist-upgrade », remember lemma 1 ? They just avoid to clic on the orange notification (which is sometimes a red arrow, I don’t understand the logic), avoiding even critical upgrade. This week-end, I just came accross a laptop when I was a bit astonished because applications were not available in the repository. I discovered that the laptop was still running Feisty 7.04 because « Upgrade can break things ». (for the record, the laptop spend the afternoon upgrading to 7.10 then 8.04 then 8.10). If I had discovered this laptop a few months later, after 7.10 lifetime, I would have no upgrade paths left !

I believe that for 9.10, we will have to think a lot about our upgrade process. Some ideas that should not be that hard to implement :

• Intelligently try apt-get -f install and retry apt-get dist-upgrade when failing
• Ask all the questions before beginning the upgrade process
• When booting, finish all apt-get upgrade and install process who were left unfinished. Explain the delay in the boot screen so the user understand that, next time, it should not reboot until the upgrade is finished
• During the upgrade, display an estimation of the time left. Maybe block the shutdown/reboot (at least the one from the gnome panel) or prompt a confirmation box

Also, what would be interesting is to split the upgrade in several « partial upgrade » of a subset of package. On this subset is downloaded, it can be upgraded while the rest is being downloaded. It would also permit to split the upgrade process in multiple days so you are not stuck four hours in front of your computer. But I admit that it might not be an easy thing to do with apt-get…

Not related : If you want to discuss stuffs about Ubuntu or are interested by a « Getting Things Done »-type application for Gnome, just poke me on the GNOME booth at FOSDEM and say « How to get things done in Gnome ? » (I’m more or less like my hackergotchi, it should not be that hard).