During an apt full-upgrade, I sometimes get asked whether to keep a modified config file or install the package maintainer's version. A diff can be hundreds of lines long, and it's hard to tell which changes are mine. Is there a manageable way to handle this, especially across several machines?
How do you make config file prompts less painful during apt upgrades?
Asked by
!sort~the+coaster
Answers
The prompt means the installed file differs from the version the package originally supplied, and the new package also has a different version. A script can have changed it, so it doesn't necessarily mean you edited it yourself. The diff shown there compares your current file with the new one. It doesn't isolate your changes from the old default.
If you're unsure, keeping the current file is the default. That lets the upgrade continue, but it can leave you without new settings or fixes. The maintainer's version is normally saved alongside it with a .dpkg-dist suffix, so you can review it afterward. Check the actual files before relying on that, and pay particular attention to security-sensitive settings in files such as login.defs.
Reply to this answer
For the next upgrade, keep a record of your config changes as you make them. Version control for selected files under /etc is one option. A short note about why a setting was changed can be just as useful as the diff itself.
For several machines, a configuration management tool or a shared set of documented settings can make it easier to apply the same decisions consistently. Still check for machine-specific differences before copying files across.
Reply to this answer
Where a service supports includes or a config directory, put your local overrides in a separate file rather than editing the package's main config. That can make future upgrades much less noisy. Check the service's loading order and syntax first. Not every config file, including login.defs, has that kind of mechanism.
Reply to this answer
A giant diff doesn't automatically mean hundreds of meaningful settings changed. Comments, formatting, or a major rewrite of the defaults can make it look much worse. Use D for a quick look, or Z to open a shell and compare the files with a tool you're comfortable with. Focus on active settings and whether their behavior has changed.
If you have a copy of the old package default, comparing that with your current file helps separate local changes from the maintainer's changes. Then compare both with the new version before merging.
v7~sparebutton_316:
It's worth checking the package documentation or release notes too, particularly for a major distribution upgrade. A setting that used to work may have changed meaning or become obsolete.
Reply to this answer
You can configure dpkg to choose a policy automatically, but that trades prompts for unattended decisions. Keeping old files everywhere can miss new defaults. Replacing them everywhere can discard local configuration. For a major upgrade, I'd review the affected files rather than blindly force either option.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Crenlet+briefly:
Choosing the maintainer's version can also overwrite local settings you still need. Back up the current file before making that choice if you want an easy way back.