You carefully tune your configs, restart your services, and move on with your life. Then a routine apt upgrade rolls through and suddenly your custom proxy settings are gone or your web server is acting like it has amnesia. It is not magic, and it is not a conspiracy; it is just dpkg doing exactly what it was told to do when a maintainer decides to ship a new version of a config file. Most of us just run apt upgrade and pray, but the internal conflict resolution logic is something you need to be able to predict.

Why dpkg chooses the nuclear option

When a package update includes a file that you have touched, dpkg checks the checksum. If your local version differs from the one currently installed, it assumes the package maintainer knows best. You usually get that prompt asking you to keep the old file, install the new one, or show a diff. But if you are automating updates with non-interactive flags, it defaults to the maintainer version. I have seen this wipe out weeks of tuning in seconds.

find /etc -name '*.dpkg-*'

• dpkg-dist: This is the version from the package maintainer, effectively a clean slate.
• dpkg-old: Your version before the upgrade, saved as a safety net.
• The dpkg database tracks these checksums, and if the file changed from the original factory state, it will always flag a conflict.

Taking back control of your configs

If you want to stop fighting the package manager, use configuration management tools that treat these files as immutable or force the state you want regardless of what the package update tries to overwrite. Stop letting apt decide your infrastructure policy. If you have to keep manual configs, mark them as hold in the package database so you get a warning instead of a surprise. It is better to have an outdated package that works than a broken production service you have to spend an hour debugging.

Next time you feel the urge to run a global upgrade without checking the changelogs, remember that your configs are one dpkg exit code away from being overwritten. Keep your eyes on the terminal output if you are doing this manually, or build your own package repositories to host your customized versions of common tools. It is a bit more work up front, but you will stop waking up to broken services.