Conflicts with PAM configuration files when upgrading system

Because I did not want to alter the live configuration of PAM on the system, I ended up using a chroot jail to setup a default PAM configuration so I can view the differences:

# lsb_release --codename
Codename:       trusty
# debootstrap trusty /tmp/foo
I: Retrieving Release 
I: Retrieving Release.gpg 
  ...

View the differences:

for f in common-{account,auth,password,session,session-noninteractive}; do
  echo ==== $f ====
  diff --unified /etc/pam.d/$f /tmp/foo/etc/pam.d/$f
done

dpkg should prompt and allow you to see a diff (with D) in case there are changes made to your configuration files:

Configuration file `/etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] 

Update: from the comment below the problem is with packages that don't drop complete configuration files (which is where the above behaviour is triggered), but with files that use a scripted approach to generate configuration files. The Debian policy manual describes that as:

E.2 Fully-featured maintainer script configuration handling

For files which contain site-specific information such as the hostname and networking details and so forth, it is better to create the file in the package's postinst script.

This will typically involve examining the state of the rest of the system to determine values and other information, and may involve prompting the user for some information which can't be obtained some other way.

When using this method there are a couple of important issues which should be considered:

If you discover a bug in the program which generates the configuration file, or if the format of the file changes from one version to the next, you will have to arrange for the postinst script to do something sensible - usually this will mean editing the installed configuration file to remove the problem or change the syntax. You will have to do this very carefully, since the user may have changed the file, perhaps to fix the very problem that your script is trying to deal with - you will have to detect these situations and deal with them correctly.

If you do go down this route it's probably a good idea to make the program that generates the configuration file(s) a separate program in /usr/sbin, by convention called packageconfig and then run that if appropriate from the post-installation script. The packageconfig program should not unquestioningly overwrite an existing configuration - if its mode of operation is geared towards setting up a package for the first time (rather than any arbitrary reconfiguration later) you should have it check whether the configuration already exists, and require a --force flag to overwrite it.

That means you need to rely on the packageconfig program, for PAM /usr/sbin/pam-auth-update, to provide a dry-run or preview option.

And as far as I can tell /usr/sbin/pam-auth-update does not offer such a feature.