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

Handling of configuration files not shipped with a newer package version



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:

[..]
/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, purging
docbook-xml will not purge all configuration directories anymore:

dpkg - warning: while removing docbook-xml, directory `/etc/xml' not empty so not removed.
dpkg - warning: while removing docbook-xml, directory `/etc/sgml/docbook-xml' not empty so not removed.
dpkg - warning: while removing docbook-xml, directory `/etc/sgml' not empty so not removed.

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? Should I ask the user
via debconf? Then I could avoid the need of the postrm-removal of still
existing directories. 

Regards, Daniel



Reply to: