Bug#584185: dpkg-maintscript-helper: rm_conffile doesn't work when removing last file in directory

[Ryan Niebur]

Package: dpkg
Verison: 1.15.7.2
Severity: normal

Because of the order dpkg and dpkg-maintscript-helper do things, when
I use dpkg-maintscript-helper on the last file in a directory, I get
this:

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?

Cheers,
Ryan

--
_________________________
Ryan Niebur
ryanr...@gmail.com

[Raphael Hertzog]

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).

Cheers,
--
Raphaël Hertzog

Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Michael Biebl]

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

[Guillem Jover]

Hi!

On Sun, 2013-06-16 at 17:25:31 +0200, Michael Biebl wrote:
> 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:

[…]

> $ sudo dpkg -i
> ../upload/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

[…]

This is just another case of dpkg being unable to do the correct thing
due to untracked system files (filed in another bug report).

> 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?

I think officializing dpkg-maintscript-helper was a mistake to begin
with, and that's why I've never wasted time in what to me is a dead
end. Instead, for 1.17.x I'm planning to finish up the conffiledb
support and tracking of external files in dpkg proper.

> 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?

Personally I don't use dpkg-maintscripts-helpers in any of my
packages, I find it too ugly for my taste. But given that your package
is already using it probably c/ is good enough for now.

Thanks,
Guillem

[Michael Biebl]

Hi Guillem,

Am 16.06.2013 19:15, schrieb Guillem Jover:
> On Sun, 2013-06-16 at 17:25:31 +0200, Michael Biebl wrote:

> This is just another case of dpkg being unable to do the correct thing
> due to untracked system files (filed in another bug report).
>
>> 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?
>
> I think officializing dpkg-maintscript-helper was a mistake to begin
> with, and that's why I've never wasted time in what to me is a dead
> end. Instead, for 1.17.x I'm planning to finish up the conffiledb
> support and tracking of external files in dpkg proper.

This issue is not really about external files, but handling of
conffiles. But maybe I just misunderstand what you mean with conffiledb.

Would be glad if you can elaborate on how that would influence conffile
handling, i.e:
1/ removing of obsolete conffiles
2/ renaming of conffiles (within the same package)
3/ moving of conffiles between packages

>> 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?
>
> Personally I don't use dpkg-maintscripts-helpers in any of my
> packages, I find it too ugly for my taste. But given that your package
> is already using it probably c/ is good enough for now.

As I needed a solution now and can't really wait until this support
lands in dpkg, I've decided to go with b/ in this particular case.
I know, that removing obsolete conffiles in preinst doesn't properly
handle aborted upgrades. But it seemed cleaner to me then c/ and I don't
just want to leave cruft around in /etc.

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Guillem Jover]

On Sun, 2013-06-16 at 19:24:45 +0200, Michael Biebl wrote:
> Am 16.06.2013 19:15, schrieb Guillem Jover:
> > This is just another case of dpkg being unable to do the correct thing
> > due to untracked system files (filed in another bug report).

> > On Sun, 2013-06-16 at 17:25:31 +0200, Michael Biebl wrote:
> >> 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?
> >
> > I think officializing dpkg-maintscript-helper was a mistake to begin
> > with, and that's why I've never wasted time in what to me is a dead
> > end. Instead, for 1.17.x I'm planning to finish up the conffiledb
> > support and tracking of external files in dpkg proper.
>
> This issue is not really about external files, but handling of
> conffiles. But maybe I just misunderstand what you mean with conffiledb.

Well, dpkg-maintscript-helper moves files around to pathnames unknown
to dpkg, so in a sense it's about untracked files. :)

> Would be glad if you can elaborate on how that would influence conffile
> handling, i.e:
> 1/ removing of obsolete conffiles

There's the two main cases here, the first removing unmodified obsolete
conffiles, which I think it's pretty uncontroversial that dpkg should
just remove them (I'll start a discussion on d-devel, due to the
behaviour change, once I'm handling this). Then there's modified obsolete
conffiles, either to be taken over by another package, or just not used
any longer, which is trickier and I think would need to be handled by
the maintainer telling dpkg upfront from a maintainer script or in a
declarative way what to do.

> 2/ renaming of conffiles (within the same package)
> 3/ moving of conffiles between packages

I think I've started work already on a dpkg-conffiles command that would
handle some of these actions, including registering confguration files,
to be able to replace ucf completely. So the maintainer would either
declare this or tell dpkg through dpkg-conffiles what to do.

> >> 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?
> >
> > Personally I don't use dpkg-maintscripts-helpers in any of my
> > packages, I find it too ugly for my taste. But given that your package
> > is already using it probably c/ is good enough for now.
>
> As I needed a solution now and can't really wait until this support
> lands in dpkg, I've decided to go with b/ in this particular case.
> I know, that removing obsolete conffiles in preinst doesn't properly
> handle aborted upgrades. But it seemed cleaner to me then c/ and I don't
> just want to leave cruft around in /etc.

Whatever works for you. :)

[Raphael Hertzog]

Hi,

On Sun, 16 Jun 2013, Michael Biebl wrote:
> 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?

Mainly because it means that we're more likely to move it between separate
filesystems and thus increase the chances of problems. It also makes it
more complicated to handle in dpkg-maintscript-helper (at least if we want
to keep the intermediate storage place relatively cruft-free).

But the downsides of not doing it are also important so I'm not set on it.
I'd consider merging a patch which does it properly.

> 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?

I don't have any better idea right now.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Liberate the French translation of the Debian Administrator's Handbook:
→ http://www.ulule.com/liberation-cahier-admin-debian/

[Michael Biebl]

Am 17.06.2013 00:20, schrieb Raphael Hertzog:
> Hi,
>
> On Sun, 16 Jun 2013, Michael Biebl wrote:
>> 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?
>
> Mainly because it means that we're more likely to move it between separate
> filesystems and thus increase the chances of problems. It also makes it
> more complicated to handle in dpkg-maintscript-helper (at least if we want
> to keep the intermediate storage place relatively cruft-free).
>
> But the downsides of not doing it are also important so I'm not set on it.
> I'd consider merging a patch which does it properly.

I was thinking of something beneath /var/lib/dpkg, as this would be
under dpkg's control anyway. conffiles are typically not large, so I
wouldn't expect a huge impact in terms of performance (moving files
between file systems). But I certainly see, that there might be subtle
issues (different mount options for different file systems, etc).