Re: Interaction between dpkg's directory removal and dpkg-maintscript-helper

[Iustin Pop <iustin@k1024.org>]

On 2016-05-06 11:07:57, Mike Hommey wrote:
> On Fri, May 06, 2016 at 02:16:32AM +0200, Iustin Pop wrote:
> > Hi,
> > 
> > I'm not sure if this is a bug or if I'm doing something wrong, looking
> > for advice. If one wants to deprecate a conffile locate in an otherwise
> > empty directory (let's say /etc/foo/bar), the following happens at new
> > package install time:
> > 
> > - before files unpacking, new-preinst is called; from
> >   dpkg-maintscript-helper manual, at this stage the conffile is renamed
> >   to bar.dpkg-remove (assuming not changed by user)
> > - new package files are unpacked; at this point, the new package doesn't
> >   own the conffile anymore, so dpkg doesn't have any tracked file under
> >   /etc/foo, so it tries to remove the directory; however this fails due
> >   to the /etc/foo/bar.dpkg-remove
> > - the new package is configured, and the postinst call to
> >   dpkg-maintscript-helper now remove /etc/foo/bar.dpkg-remove, but
> >   leaves /etc/foo as an unowned, dangling directory
> > 
> > At least, this is my understanding from reading policy and from piuparts
> > output. I can workaround it by manually removing the directory (if
> > empty), but seems somewhat out-of-place. Thoughts?
> 
> See also: bug 815969.

I see, thanks for the fast reply. rmdir it is then…

iustin