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. 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:~# If the file didn’t exist in
the previously installed version, it is installed, so you get new
Or you could just make sure to purge the package before (re)installing it, that will make the package system forget about all configuration files. Removing a package is not enough for “complete reinstall”. aptitude purge foobar, apt-get remove –purge foobar or dpkg –purge foobar.
dpkg-reconfigure foo wouldn’t do the trick ? It would have given you the default conffile without having to reinstall the whole package, wouldn’t it ?
Hmm, your Arse feed is a bit broken, giving “http://www.davidpashley.com/blog/debian/confmiss.html” as the <link> for this entry, which is a blank page.
IIRC if you, as the admin, delete a conffile file, the Debian system assumes you know what your doing. So it assumes you don’t want it reinstalled.
Kevin, no system should behave like that, even if you know what you’re doing. you might change your mind. the system should ask if you want the missing config files (y/N).