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. 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]
Re: Handling of configuration files not shipped with a newer package version
On Sat, May 26, 2007 at 03:00:31PM +0200, Daniel Leidert wrote: 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: , 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? I think the logic is supposed to be that dpkg doesn't warn until after postrm purge phase, since the maintscripts are supposed to act as a kind of dpkg module and the user shouldn't be bugged just because there's a config file which is not a conffile. Also added I think was that dpkg would keep reattempting removal of dirs at relevant times after the first attempt after the conffiles in that dir were removed. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
