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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527093206.gc32...@dorei.kerker.die-welt.net