Outsmarting dpkg's conffile handling
dpkg has a very useful feature where if you delete a conffile (pretty much everything under /etc and a few other files) it isn't replaced when you upgrade the package[0]. This behaviour was confusing me for a while until I realised what was happening. I was attempting to reinstall a package to get the default configuration files back that had been accidentally deleted, but no matter what I tried, the files didn't exist after running dpkg. Once I figured out that dpkg had this behaviour the solution was simple; use the --force-confmiss command line argument.
root@quux:~# dpkg --force-confmiss -i /tmp/foo_2.0.0-build.14_all.deb (Reading database ... 33418 files and directories currently installed.) Preparing to replace foo 2.0.0-build.14 (using .../foo_2.0.0-build.14_all.deb) ... Unpacking replacement foo ... Setting up foo (2.0.0-build.14) ... Configuration file `/etc/foo/foo.xml', does not exist on system. Installing new config file as you request. root@quux:~#
[0] If the file didn't exist in the previously installed version, it is installed, so you get new configuration files.



