Handle Config File Collisions During Updates Better
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
- Started by
- Completed by
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-
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
