Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 21986 ideas, 135057 comments, 2615221 votes
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas
Idea #14743: Prompt for config file changes ahead of time for upgrades.

Written by wolfwitch the 23 Oct 08 at 16:44. Related project: Update manager. Status: New
Rationale
I'm in the process of upgrading to Intrepid, and noticed once again something that really annoys me...

The upgrade process takes 4+ hours, so it is something I would prefer to start and walk away from, sleep through, etc. Instead, after 1 hour- it stops to ask me what to do with Config File X. A half hour later, it wants to know what to do with Config File Y, then Config File Z (you get the picture).

I would like to see one of two things:

If possible (and this would be an ideal)- the upgrade system should check for any of these config file conflicts ahead of time, and prompt at the beginning of the process for the user's preferences.

Or- ask the user for a default answer- Do you want to overwrite existing configuration files with the new package's default, or do you want to keep your customized configuration files?

Either of the options in this last choice could cause problems, and the user should be warned as-such, however- most users with customized configurations files either know what they are doing and can "fix" them later, or the files have been corrupted over time and would be fixed by the change.

A third solution to this would simply be to queue all configuration file changes for the final stage of the upgrade, just before un-installing deprecated/unneeded packages.

54
votes
closed
Solution #1: Auto-generated solution of idea #14743
Written by wolfwitch the 23 Oct 08 at 16:44.
Ubuntu Brainstorm was updated in January 2009. Since the idea #14743 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

Propose your solution

Attachments
No attachments.


Duplicates


Comments
asdasd wrote on the 24 Oct 08 at 13:16
Interesting. I'm running the Intrepid update myself right now and just logged in to brainstorm to post this same idea. Since I knew it would, as usual, prompt me to act on configuration changes, I couldn't take Ubuntu's advice and go have some coffee while the update does it thing, as it would most likely be waiting for my response at a painfully early stage.

What I had in mind, though, is that, instead of simply prompting the user about config changes and waiting for a response, there should be a timeout after which it's automatically backgrounded and dealt with at a later stage.

But I was left wondering: is there any need/advantage to warn the user about config changes in the "configuring packages" stage, rather than after install?

urandom wrote on the 24 Oct 08 at 15:04
much simpler would be to just delay all this user interaction for after the install is done.

foxmike wrote on the 24 Oct 08 at 16:25
This is the first time I'm trying a network upgrade since I began with Ubuntu with the Breezy Badger... So I got caught with this one as well! And it annoyed me.

On an other hand (correct me if I am wrong), it would be hard to do that action prior the download/installation has begun, because the installer is not aware about what configuration file the user has change, nor does it knows what configuration file will be changed by the update.

Doing that prompting at the all end of the update looks like hard to do, because of the update run the update has to do: first download all the packages, then, each packages 1 at the time, run a pre-remove script from the old package, remove the old package, run a pre-install script from the new package, install the actual package, run a post-install script from the new package...

Those promptings are fired by one of the above-mentionned scripts. Delaying such a script would leave the package (usually an important package) in an unconfigured state, and that would prevent other packages (possibly important as well) to install, for dependences reasons.

wolfwitch wrote on the 24 Oct 08 at 16:46
An alternate to this, which I realized while updating some RPM-based servers this morning, would simply be to save the current config file as filename.config.save (or something similar) and create the package-default config. Log these to a text file and display it at the end of the update process. That way- the update can complete without user interaction (which is what we want), and can still let the user know what configs may need to be updated.

As I already said- chances are that if a config file is "non-standard"- it is either corrupted or was manually changed by the user (in which case that user should already know what has to happen to fix it). Or- the file NEEDS to be changed due to new features in the package, in which case the new config file needs to be used anyway.

ugtar wrote on the 24 Oct 08 at 20:46
Yeah this would be nice. I wouldn't necessarily like it to just do some default action though, unless it saved all the files it did that action to and told me about them later, like wolfwitch suggests in his last comment.

Usually I remember to reapply my changes I've made to something like my ssh_config, but I don't always remember the line I (un)commented out in /etc/acpi/fubar.conf that made my computer able to wake up from sleep or something. There can be many small tweaks like that to make a usable system. If the installer defaults to overwriting them and backing them up or something, it should tell you about those files at the end.

freshbase wrote on the 25 Oct 08 at 02:09
I agree with wolfwitch's last comment too; if it could back up your existing config files and then show you a list when the process is done that would be fantastic.


Post your comment