Re: Handling of configuration files not shipped with a newer package version

[Daniel Leidert <daniel.leidert.spam@gmx.net>]

Am Samstag, den 26.05.2007, 00:36 -0400 schrieb Justin Pryzby:
> On Sat, May 26, 2007 at 04:08:32AM +0200, Daniel Leidert wrote:
> > Hi,
> > 
> > The docbook-xml package 4.4 shipped a really old version 3.1.7, that was
> > dropped with package version 4.5. The package itself ships a
> > configuration file for every released version:
> [ Note: Is it a conffile. ]
> 
> > [..]
> > /etc
> > /etc/sgml
> > /etc/sgml/docbook-xml
> > /etc/sgml/docbook-xml/3.1.7
> > /etc/sgml/docbook-xml/3.1.7/dbgenent.ent
> > [..]
> > 
> > Now what is the best/recommended way to handle the removal of the 3.1.7
> > version? A normal upgrade tries to remove the
> > directory /etc/sgml/docbook-xml/3.1.7, which is impossible,
> > because /etc/sgml/docbook-xml/3.1.7/dbgenent.ent still exists. Although
> > dpkg still knows, that the file belongs to docbook-xml
> You can check the page that used to be at dpkg.org regarding removal
> of an obsolete conffile.
> 
> Basically you check: [ -e "$f" ] && dpkg --compare-version &&
> 	[ `md5sum "$f" |sed -e 's/ .*//` = "$oldmd5" ] && rm -iv "$f"
> or such.
> 
> http://wiki.debian.org/DpkgConffileHandling

Thanks.

> > , purging
> > docbook-xml will not purge all configuration directories anymore:
> > 
> > dpkg - warning: while removing docbook-xml, directory `/etc/xml' not empty so not removed.
> I think this should work with etch dpkg?

Tested in an Etch pbuilder chroot. It produces the warnings I posted.
dpkg -L does list /etc/sgml/docbook-xml/3.1.7/dbgenent.ent as part of
docbook-xml after update, but it doesn't
list /etc/sgml/docbook-xml/3.1.7 anymore. A mis-behaviour of dpkg?

> > because it doesn't try to remove /etc/sgml/docbook-xml/3.1.7 anymore.
> > How is such a situation handled "best"? I guess, I must add at least
> > some code to postrm to make sure these directories are removed too,
> > if /etc/sgml/docbook-xml/3.1.7 still exists. But should I try to remove
> > this obsolete directory already during upgrade?
> Conditional on the above .. conditions, yes.
> 
> > Should I ask the user via debconf?
> This would be considered an overuse of debconf.

That's why I asked.

Thanks for the wiki hint. That's exactly, what I was looking for.

Regards, Daniel