[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: correctly using other packages in postrm



Hi Evgeni,

On Thu, May 27, 2010 at 11:32:06AM +0200, Evgeni Golov wrote:
> 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

Does dbconfig-common know about all of these config files?

I think it's the responsibility of dbconfig-common to track them, and remove
them on purge.  That way if your package is purged while dbconfig-common is
installed, the config file is removed, and if dbconfig-common is removed
before purge, a dpkg --purge dbconfig-common can still clean it up.

This is similar to how ucf's cache is already handled, btw.

> 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?).

Piuparts should include purging dbconfig-common (i.e.: all dependencies that
it installed) as part of this test.  If it does, and the config file is left
behind, this is a dbconfig-common bug, IMHO.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org


Reply to: