On Wed, Jun 02, 2010 at 07:50:47AM +0200, Raphael Hertzog wrote: > On Tue, 01 Jun 2010, Ryan Niebur wrote: > > Preparing to replace midori 0.2.2-1 (using midori_0.2.6-1_i386.deb) ... > > Moving obsolete conffile /etc/midori/extensions/libadblock.so/config out of > > the way... > > Unpacking replacement midori ... > > dpkg: warning: unable to delete old directory > > '/etc/midori/extensions/libadblock.so': Directory not empty > > dpkg: warning: unable to delete old directory '/etc/midori/extensions': > > Directory not empty > > dpkg: warning: unable to delete old directory '/etc/midori': Directory not > > empty > > Setting up midori (0.2.6-1) ... > > Removing obsolete conffile /etc/midori/extensions/libadblock.so/config ... > > > > This gives a lot of output and leaves the > > /etc/midori/extensions/libadblock.so directory for no reason. > > > > Is there any nice (using dpkg-maintscript-helper) way to solve this > > problem? > > It would require storing the backup conffile somewhere else which I don't > think is a good idea. > > dpkg -S /etc/midori/extensions/libadblock.so should still return midori > and the directory should also be listed in dpkg -L midori. The directory > would be removed on purge but it can't be removed at upgrade time since > it's not empty. > > But you can add the appropriate command in the postinst if this matters > to you (after the dpkg-maintscript-helper call).
I encoutered a similar issue: gnome-keyring no longer ships /etc/pkcs11/modules/gnome-keyring.module. So I used rm_conffile (via $pkg.maintscript) to remove the obsolete conffile. Basically the same thing happens: $ find /etc/pkcs11/ /etc/pkcs11/ /etc/pkcs11/modules /etc/pkcs11/modules/gnome-keyring.module $ sudo dpkg -i ../upload/gnome-keyring_3.8.2-2_amd64.deb (Reading database ... 273315 files and directories currently installed.) Preparing to replace gnome-keyring 3.8.2-1 (using .../gnome-keyring_3.8.2-2_amd64.deb) ... Moving obsolete conffile /etc/pkcs11/modules/gnome-keyring.module out of the way... Unpacking replacement gnome-keyring ... dpkg: warning: unable to delete old directory '/etc/pkcs11/modules': Directory not empty dpkg: warning: unable to delete old directory '/etc/pkcs11': Directory not empty Setting up gnome-keyring (3.8.2-2) ... Removing obsolete conffile /etc/pkcs11/modules/gnome-keyring.module ... Processing triggers for libglib2.0-0:amd64 ... Processing triggers for libglib2.0-0:i386 ... Processing triggers for man-db ... $ find /etc/pkcs11/ /etc/pkcs11/ /etc/pkcs11/modules I first intended to add rmdir --ignore-fail-non-empty /etc/pkcs11/modules rmdir --ignore-fail-non-empty /etc/pkcs11 to postinst (after #DEBHELPER#). But there is another package [1] shipping an empty /etc/pkcs11. Which means the directory is potentially owned by another package, so I can't just remove it in postinst. And messing around with dpkg -S in postinst is starting to get ugly. If dpkg-maintscript-helper would move the file outside of /etc, this issue would be solved. Raphael, What's the reason you don't consider this a good idea? As for my case (gnome-keyring), I currently see three options: a/ don't bother cleaning up /etc/pkcs11 b/ don't use dpkg-maintscripts-helpers, clean up the obsolete conffiles in preinst (using [2]) and let dpkg remove the empty dir c/ use dpkg-maintscript-helpers and remove the directory in postinst, while guarding the rmdir with a dpkg -S check Do you have another, better idea? What would be your recommendation? Cheers, Michael [1] http://packages.debian.org/sid/amd64/opencryptoki/filelist [2] https://wiki.debian.org/DpkgConffileHandling -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
