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