too many annoying interruptions during distribution upgrade

[Robert Persson]

I am at this moment upgrading from feisty to gutsy beta. I hoped I could just set it going, answer a few questions, and then forget about it for a few hours while I took the kids to their swimming lessons etc. However I came home and found that waiting for me for an hour or two was a box asking me whether I wanted to change ownership on files used by mldonkey. I come back another couple of hours later and I find that I need to give permission for samba and a couple of other services to be restarted. Unfortunately this reminds me too much of the ordeal of trying to install MS windows (I know it's not really as bad as that, but it's still frustrating).

What would be much more user-friendly would be for questions such as the one about mldonkey to be asked before the whole process starts. Perhaps this would mean having a central list of questions that would be asked by dpkg-configure for the various packages so that these questions can be asked in advance and the answers fed to dpkg-configure at the appropriate time; I don't really know enough about this sort of thing, so probably someone can come up with a much more elegant solution than I could ever think of.

I also wonder why the question about restarting cupsys, samba etc. should be asked at all. After all, if you are upgrading your system then you know you are going to have to reboot at some point, so you shouldn't really be surprised if a few services are briefly interrupted. Perhaps it might still be an issue on a server installation, but surely not for a desktop user?

In short, you shouldn't have the upgrade process repeatedly interrupted by questions about this and that. You should be able to have a cup of tea and sit in the garden and enjoy the rain and let it chug along on its own.

[Michael Vogt (mvo)]

Thanks for your bugreport.

Update-manager is really just the messenger here but I fully agree that too many packages ask unneeded questions. What else beside restarting services and mldonkey did you got?

[Robert Persson (ireneshusband)]

Unfortunately I can't remember which other packages were involved; I was just glad to get the business over with and to be able to get on with my work.

However I have noticed another problem related to this, which is that many packages were left in an unconfigured state after the upgrade. They only come to light when I upgrade something or, as happened today, when I was installing a 3rd-party package (jucetice-jost) I had aliened from an rpm. The packages in question today were libX11-data and libX11-6. In other words, despite all these interruptions, the job of configuration doesn't get completed properly.

[Diego Gaustein (gregorovius)]

My $0.02: I agree completely. It would be good interface design to ask every question first, so the user doesn't have to check every 5 minutes to see if it requires input. In my case, I had to agree to several /etc overwrites, a list of services to be restarted by PAM, etc.

[Robert Persson (ireneshusband)]

see also #154198

[Richard Birnie (rbirnie-deactivatedaccount)]

I agree that this is an annoyance and a lot of packages ask too many questions. However as Michael Vogt pointed out Update manager is really just the messanger. As I understand it (and I may be wrong) the questions come from the configuration scripts contained in the individual packages. So to ask all the questions at the start would require a central database of all the questions that might ever be asked by all the packages in the ubuntu repositories and which package they come from. This would then have to be checked against the list packages a given user actually has installed and the relevant questions extracted. With nearly 25000 packages available in the ubuntu repositories this is obviously not trivial

[tz (thomas-mich)]

It would probably be possible to add a "Prompts: always | overwrite | never" tag to the Debian control file, then process all those that have it set to never, then unknown, then overwrite, then always.

The sledgehammer approach would be to kill any dpkg -i that prompts and have the manager continue with the next one when there is a large group. Then apt-get install will detect the packages as partially installed and rerun the postinst scripts.

I will make notes, at least if the upgrade ever gets past the downloading phase...

[Omegamormegil (omegamormegil)]

I agree, but I think there should be a way to retain the config file you initially said not to use.

My idea would have the upgrade utility automatically use the new configuration files whenever a prompt would have been displayed, and would make backups of the old config files, renaming them with the previous ubuntu release codename (ie "configfile.gutsy" during an upgrade from gutsy to hardy).

After the upgrade, the user could be presented with a GUI displaying which files were automatically replaced, with a diff displayed, and with a button allowing the user to revert each individual file to it's old version. If the user would opt to keep the old version, the system would instead make a backup of the package maintainer's version renamed with the new release codename (configfile.hardy), so that you could change your mind later.

This would prevent the updater from having to know in advance what packages would ask questions, and would also keep the upgrade process from halting to wait for the user to respond mid-upgrade.

[Robert Persson (ireneshusband)]

From my experience of using gentoo I have mixed feelings about Omegamormegil's suggestion. On the one hand it should install a system in working order, while giving the user the option of bringing back what works well from their previous configuration. On the other, it will mean that the user is presented with a huge number of decisions to make. I only ever knew how to deal with the choices etc-update presented with me with because I was an experienced nerd. And even then my decisions ended up being based on hunches rather than a precise understanding of what was going on. For someone who isn't confident with computers this would be a serious barrier. Add to this how time-consuming this process could be and you will start to have some seriously anxious users.

I suspect there is scope for refining Omegamormegil's suggestion in some way, for instance by screening out trivial decisions or by offering suggestions.

As for diffs, they should not be displayed unless the user specifies that s/he wants to see them. They would make users feel that it was expected of them to understand config files and scripts they don't understand.