correctly using other packages in postrm

[Evgeni Golov <evgeni@debian.org>]

Hi,

piuparts has discovered a problem with one of my packages [1] and while
analyzing it, Holger and I came to the result, that piuparts *may* be
working wrong here - it removes the depends before purging my
(the tested) package.
Thus we are seeking for your opinion and suggestions.

For those who do not want to read the maintainer-scripts of my package,
here is what you need to know (src:bley, using dbconfing-common for
database configuration): 

 Depends:
  ... dbconfig-common ...

 postrm:
  ...
  if [ -f /usr/share/dbconfig-common/dpkg/postrm ]; then
        . /usr/share/dbconfig-common/dpkg/postrm
        dbc_go bley $@
  fi
  ...

This means that we *try* to execute the postrm-hook of dbconfig-common
in our postrm, but only if it's there. Policy 7.2 says "The Depends
field should also be used if the postinst, prerm or postrm scripts
require the package to be present in order to run. Note, however, that
the postrm cannot rely on any non-essential packages to be present
during the purge phase.", which allows dbconfig-common to be gone
*before* our postrm is executed. If it is gone, the hook isn't called,
/etc/dbconfig-common/bley.conf isn't removed and piuparts warns about 
it.

That's perfectly correct, we leave a stale config file here, so how to
fix it?
Trivial solution would be something like:
  if [ -f /usr/share/dbconfig-common/dpkg/postrm ]; then
        . /usr/share/dbconfig-common/dpkg/postrm
        dbc_go bley $@
  else
        rm -f /etc/dbconfig-common/bley.conf
        if which ucf >/dev/null 2>&1; then
            ucf --purge /etc/dbconfig-common/bley.conf
            ucfr --purge bley /etc/dbconfig-common/bley.conf
        fi
  fi

Everyone using dbconfig-common would have to add something like this to
his/her postrm. (And everyone using other packages in a similar way too)

Alternatively, we could modify piuparts not to remove dbconfig-common
before the tested package isn't gone (or actually: not to try to remove
any deps before the tested package isn't gone) and thus ignore this
problem, defining it as "not usual usecase" (who tries to remove deps
before removing the package itself?).

What do you think? piuparts is correct and we should fix all affected
packages? Or make the piuparts check less strict/more real-world like?

Regards
Evgeni Golov

[1] http://piuparts.debian.org/sid/source/b/bley.html

-- 
Bruce Schneier can read and understand Perl programs.