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
