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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]