What does "new" mean to "dpkg --force-confnew"?

Question

I was recently given the task of maintaining & porting to Trusty an in-house .deb package that overwrites (using --force-overwrite) config files from other packages with customized versions, after which apt-get install -f -y is run to install a bunch of related packages listed as dependencies, some of which are the rightful owners of those config files (Keep your snide comments and screams of terror to yourself). Note that this package marks the config files as config files rather than as regular files.

In the process of trying to clean the thing up, I discovered that if apt-get is passed -o Dpkg::Options::="--force-confold", then the config files from our custom package will be overwritten by the dependencies' versions, while if -o Dpkg::Options::="--force-confnew" is used, our package's files will remain at the end.

However, the dpkg manpage states:

confnew: If a conffile has been modified and the version in the package did change, always install the new version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred.

confold: If a conffile has been modified and the version in the package did change, always keep the old version without prompting, unless the --force-confdef is also specified, in which case the default action is preferred.

Because the "new version" is installed while the "old version" is kept, this seems to imply that the "new version" is always the one in the package being installed at that moment, and thus passing -o Dpkg::Options::="--force-confnew" to apt-get should cause the dependencies' config files to overwrite the ones that our package installed a moment before. Why is this not the case? Is the actual meaning of "new version" actually based on timestamps (which would just raise further questions)? Is this a bug in the documentation and/or implementation of dpkg? Is this just a hairy edge case brought about by two packages laying claim to the same config files that the dpkg developers thought no one would ever be insane enough to stumble across? What?

Answer 1

I believe I've figured out what was going on: Because the dependencies for the custom package are not installed when dpkg -i is run, the package is registered with the package system and neither it nor its config files are installed at that time. When apt-get install -f is run, the dependencies are installed, and then the package itself is installed, and it's at this point that the config files are installed and the --force-conf* policy passed to apt-get takes effect. So it wasn't a matter of --force-confnew so much as a matter of order of events when installing a dependency-lacking package with dpkg.