Re: Handling of configuration files not shipped with a newer package version
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.
> > , 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.