Handle Config File Collisions During Updates Better

Registered by Robbie Williamson on 2009-04-22

Look at handling customized configuration files better during updates by allowing users to save the old one, provide a summary of configuration file collisions at the end of the update, along with the location/names of their original and replaced versions. This would help users resolve issues they potentially get because of the collision.

Blueprint information

Status:
Not started
Approver:
Robbie Williamson
Priority:
Low
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Deferred
Milestone target:
None

Related branches

Sprints

Whiteboard

IMHO, an important part of this would be to stop asking the user about files he never customized himself. CUPS for example is handled by system-config-printer, and the user should not be bothered about its config file being customized: just merge it automatically.

Integrating directly into dpkg something like ucf for intelligently handling conffile changes automatically for all packages would be great. --liw

2009-06-15: one (easy) step forward is to provide a unified view of all conffile changes at the end of the release upgrade. This would not include ucf for now because there is currently no way to get notified about changes (dpkg conffile prompts are advertised via the dpkg status pipe). One problem with batching all conffile changes at the end is that it does mean that e.g. daemon that get restarted during install would work with the --conf-old or conf-new setup. Not a big deal (normally) on release upgrades as we require a reboot anyway, but a problem for normal upgrades.

2009-06-17: Unfortunately, we don't have the resources within the Foundations team to do this for the Karmic cycle. Will defer to Karmic+1. -robbie.w

(?)

Work Items