Debian Bug report logs - #316521
dpkg: incomplete cleanup of empty directories

version graph

Package: dpkg; Maintainer for dpkg is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg is src:dpkg.

Reported by: Frank Küster <frank@debian.org>

Date: Fri, 1 Jul 2005 14:49:08 UTC

Severity: normal

Merged with 348133, 538429, 625241, 664822

Found in versions dpkg/1.10.28, dpkg/1.15.8.10, dpkg/1.15.3.1, dpkg/1.13.11.0.1, dpkg/1.13.13, dpkg/1.13.16, dpkg/1.10.9

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to Frank Küster <frank@debian.org>, teTeX maintainers <debian-tetex-maint@lists.debian.org>:
Bug#316521; Package tex-common. Full text and rfc822 format available.

Acknowledgement sent to Frank Küster <frank@debian.org>:
New Bug report received and forwarded. Copy sent to Frank Küster <frank@debian.org>, teTeX maintainers <debian-tetex-maint@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at maintonly@bugs.debian.org (full text, mbox):

From: Frank Küster <frank@debian.org>
To: Debian Bug Tracking System <maintonly@bugs.debian.org>
Subject: tex-common: leaves /etc/texmf/updmap.d on the system
Date: Fri, 01 Jul 2005 16:09:58 +0200
Package: tex-common
Severity: minor

In the following scenario, /etc/texmf/updmap.d/ is still on the system
after purge even after complete purge:

- Install tex-common and tetex-base_3.0-n

- remove tex-common

- purge tetex-base (it will complain about /etc/texmf/updmap.d not being
  empty, but that is okay because tex-commons conffile is still there)

- dpkg --purge tex-common: No messages, but the directory is still there.

Not very important, and maybe it's even a dpkg bug.

Regards, Frank

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-386
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer




Bug reassigned from package `tex-common' to `dpkg'. Request was from Bart Martens <bart.martens@advalvas.be> to control@bugs.debian.org. Full text and rfc822 format available.

Bug marked as found in version 1.13.13 1.10.28 1.13.11.0.1. Request was from Bart Martens <bart.martens@advalvas.be> to control@bugs.debian.org. Full text and rfc822 format available.

Severity set to `normal'. Request was from Bart Martens <bart.martens@advalvas.be> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 316521 318825 348133. Request was from Bart Martens <bart.martens@advalvas.be> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Bart Martens <bart.martens@advalvas.be> to control@bugs.debian.org. Full text and rfc822 format available.

Information stored:
Bug#316521; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Bart Martens <bart.martens@advalvas.be>:
Extra info received and filed, but not forwarded. Full text and rfc822 format available.

Message #20 received at 316521-quiet@bugs.debian.org (full text, mbox):

From: Bart Martens <bart.martens@advalvas.be>
To: 316521-quiet@bugs.debian.org
Subject: dpkg
Date: Sun, 26 Feb 2006 13:51:03 +0100
You're right, it's a dpkg bug.  How to reproduce this with dpkg 1.13.13,
tetex-base 3.0-14 and tex-common 0.15 :

ls /etc/texmf/updmap.d
apt-get install tetex-base tex-common
ls /etc/texmf/updmap.d
dpkg --remove tetex-base tex-common
ls /etc/texmf/updmap.d
dpkg --purge tex-common
ls /etc/texmf/updmap.d
dpkg --purge tetex-base
ls /etc/texmf/updmap.d

This is bug #318825.  I'll merge the bugs.




Merged 174180 316521 318825 348133. Request was from Nicolas François <nicolas.francois@centraliens.net> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 174180 198128 316521 318825 348133. Request was from Nicolas François <nicolas.francois@centraliens.net> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 174180 198128 198522 316521 318825 348133. Request was from Nicolas François <nicolas.francois@centraliens.net> to control@bugs.debian.org. Full text and rfc822 format available.

Disconnected #316521 from all other report(s). Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 316521 348133. Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Merged 316521 348133 366178. Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Disconnected #366178 from all other report(s). Request was from Frank Lichtenheld <djpig@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. Full text and rfc822 format available.

Message #39 received at 316521@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: 316521@bugs.debian.org
Cc: djpig@debian.org, Bart Martens <bartm@knars.be>, Lars Wirzenius <liw@liw.iki.fi>
Subject: dpkg: don't forget to delete directories
Date: Sun, 6 Jul 2008 17:15:53 +0200
tags 316521 - patch
retitle 316521 dpkg forgets shared directories containing manually generated files which are removed by postrm purge
thanks

The situation on this bug is a bit complicated so I'll make a summary... I
took some time to read everything.

First of all, Frank fixed the bulk of the initial problem by deferring removal of
directories containing conffiles to after the purge. This is commit
e0bea5706dd1a0accb39a28f7002d30c10b4caa6 that got fixed in dpkg 1.13.20.

However we still have one scenario where dpkg "forgets" (rightfully)
that a directory is part of a package because the package doesn't have
any packaged file inside that directory: it's when the directory is shared
with other packages. Obviously dpkg can't remove the dir since it's still
in active use by other packages.

The problem appears however when the just removed (and not yet purged)
package is responsible of a manually generated file inside that directory.
When all the other packages that share the directory are removed, nobody
owns the directory and even purging the package that created the last file
left, the directory won't be removed as it's no more associated to it.

Bart proposed a patch that basically forbids dpkg to forget the
directories as long as they are shared by multiple packages
(see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318825#27). This
is definitely not the proper solution as all removed packages would be
listed as owner of directories that they shouldn't own anymore.

Until we provide a way for packages to teach what files are generated by
each package, I only see two solutions:

- either we define that the "postrm purge" should try to remove parent
  directories too
- or we ask dpkg to remember directories that it can't remove if
  they contain at least one file not owned by any package and if they have
  a postrm script (this is the smallest subset of packages that we can
  identify and that could be responsible of the removal of the given
  directory)

Cheers,

PS: FTR, the bulk of the discussion is in 318825 and 348133.
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/




Tags removed: patch Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sun, 06 Jul 2008 15:18:05 GMT) Full text and rfc822 format available.

Changed Bug title to `dpkg forgets shared directories containing manually generated files which are removed by postrm purge' from `dpkg: forgets to delete directories when purging'. Request was from Raphael Hertzog <hertzog@debian.org> to control@bugs.debian.org. (Sun, 06 Jul 2008 15:18:06 GMT) Full text and rfc822 format available.

Merged 316521 348133 454694 538429. Request was from Sven Joachim <svenjoac@gmx.de> to control@bugs.debian.org. (Wed, 05 Aug 2009 20:33:04 GMT) Full text and rfc822 format available.

Added indication that bug 316521 blocks 566853 Request was from Niels Thykier <niels@thykier.net> to control@bugs.debian.org. (Thu, 22 Jul 2010 12:36:04 GMT) Full text and rfc822 format available.

Changed Bug title to 'dpkg: incomplete cleanup of empty directories' from 'dpkg forgets shared directories containing manually generated files which are removed by postrm purge' Request was from Jakub Wilk <jwilk@debian.org> to control@bugs.debian.org. (Sun, 10 Apr 2011 02:39:13 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Mon, 02 May 2011 23:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 02 May 2011 23:09:06 GMT) Full text and rfc822 format available.

Message #54 received at 316521@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Ondřej Surý <ondrej@debian.org>
Cc: 316521@bugs.debian.org
Subject: Re: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Mon, 2 May 2011 18:05:31 -0500
forcemerge 316521 625241
quit

Hi,

Ondřej Surý wrote:

> I don't know whether it is real dpkg bug or not, but that's something
> I have found in php5 piuparts testing.
>
> Both php5-common and php5-cli (and other SAPIs) "owns" /etc/php5
> (/var/lib/dpkg/info/*.list), now after
>
> dpkg --remove php5-cli
> dpkg --remove php5-common
> dpkg --purge php5-common
> dpkg --purge php5-cli
>
> the /etc/php5 is left in place because it was removed from
> /var/lib/dpkg/info/php5-cli.list (I guess on basis that another
> package - the php5-common still "owns" the directory).

Sounds like Bug#316521 (dpkg: incomplete cleanup of empty
directories).

One possible fix might be:

 - at removal time, if the number of packages owning a directory
   decreases to zero, try to remove it.  If that fails, keep
   ownership, until

 - purge time, at which point if the number of packages owning
   the directory has decreased to zero, try to remove it.

I am hand-waving the "keep ownership" because I don't remember
what happens to .list files for removed packages.

The above suggestion would still involve keeping empty directories
after packages are removed in some scenarios; the point would be to
make sure everything goes away at purge time, at least, to avoid
getting in piuparts's way, without regressing in the current cases
where directories are being correctly removed at removal time.

If anyone interested in working on this has any questions, please feel
free to let us know.




Forcibly Merged 316521 348133 454694 538429 625241. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Mon, 02 May 2011 23:09:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Tue, 03 May 2011 05:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 03 May 2011 05:51:03 GMT) Full text and rfc822 format available.

Message #61 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 316521@bugs.debian.org
Subject: Re: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Tue, 3 May 2011 07:46:27 +0200
Hi,

On Tue, May 3, 2011 at 01:05, Jonathan Nieder <jrnieder@gmail.com> wrote:
> forcemerge 316521 625241
> quit

And I thought I have checked the existing bugs ... probably used wrong
keywords :(. Sorry for duplicate.

> Hi,
>
> Ondřej Surý wrote:
>
>> I don't know whether it is real dpkg bug or not, but that's something
>> I have found in php5 piuparts testing.
>>
>> Both php5-common and php5-cli (and other SAPIs) "owns" /etc/php5
>> (/var/lib/dpkg/info/*.list), now after
>>
>> dpkg --remove php5-cli
>> dpkg --remove php5-common
>> dpkg --purge php5-common
>> dpkg --purge php5-cli
>>
>> the /etc/php5 is left in place because it was removed from
>> /var/lib/dpkg/info/php5-cli.list (I guess on basis that another
>> package - the php5-common still "owns" the directory).
>
> Sounds like Bug#316521 (dpkg: incomplete cleanup of empty
> directories).
>
> One possible fix might be:
>
>  - at removal time, if the number of packages owning a directory
>   decreases to zero, try to remove it.  If that fails, keep
>   ownership, until

That wouldn't work in this case:

dpkg --remove php5-cli (2->1)
# removing failed, ownership is not kept for php5-cli
dpkg --remove php5-common (1->0)
# removing failed, ownership is kept, but that's already the case
dpkg --purge php5-common
# removing failed
dpkg --purge php5-cli
# no ownership, removal not tried

>  - purge time, at which point if the number of packages owning
>   the directory has decreased to zero, try to remove it.

dtto, php5-cli is not owning the directory at this moment.

> I am hand-waving the "keep ownership" because I don't remember
> what happens to .list files for removed packages.
>
> The above suggestion would still involve keeping empty directories
> after packages are removed in some scenarios; the point would be to
> make sure everything goes away at purge time, at least, to avoid
> getting in piuparts's way, without regressing in the current cases
> where directories are being correctly removed at removal time.

At the moment the only solution I see is what I have suggested - keep
ownership of whole tree up-to-the root for directories holding
conffiles and try to remove them at purge time...

dpkg --remove php5-cli
# ownership kept for /., /etc, /etc/php5, /etc/php5/cli
dpkg --remove php5-common
# ownership kept for /., /etc, /etc/php5, /etc/php5/conf.d
dpkg --purge php5-common
# try to remove directories where ownership = 0
# i.e. remove /etc/php5/conf.d
dpkg --purge php5-cli
# try to remove directories where ownership = 0
# i.e. remove /etc/php5/cli, /etc/php5

> If anyone interested in working on this has any questions, please feel
> free to let us know.

I could work on that...

O.
-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Wed, 04 May 2011 04:21:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 04 May 2011 04:21:07 GMT) Full text and rfc822 format available.

Message #66 received at 316521@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Ondřej Surý <ondrej@debian.org>
Cc: 316521@bugs.debian.org
Subject: Re: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Tue, 3 May 2011 23:20:10 -0500
Ondřej Surý wrote:

> At the moment the only solution I see is what I have suggested - keep
> ownership of whole tree up-to-the root for directories holding
> conffiles and try to remove them at purge time...
>
> dpkg --remove php5-cli
> # ownership kept for /., /etc, /etc/php5, /etc/php5/cli

Yes, makes sense.

> On Tue, May 3, 2011 at 01:05, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> If anyone interested in working on this has any questions, please feel
>> free to let us know.
>
> I could work on that...

That would be excellent!




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Wed, 04 May 2011 09:12:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 04 May 2011 09:12:13 GMT) Full text and rfc822 format available.

Message #71 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: 316521@bugs.debian.org
Subject: Re: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Wed, 4 May 2011 11:11:10 +0200
[Message part 1 (text/plain, inline)]
Ok, so I have found the culprit. The php5-cli uses ucf and hence the
/etc/php5/cli/php.ini is not marked as conffile and so, the
hasdirectoryconffiles check fails.

The attached patch keeps the directory in the <pkg>.list (aka add it
to the leftover) if the children directory is found on the leftover
list.

There could be a slight modification to keep /. in the list as well to
be formally correct, but IMO it's not needed.

Also I have found a small bug in the matching function
hasdirectoryconffiles and I am inheriting it (since I don't think it's
major)...

If there is a conffile named:

/etc/pkg/foobar/foo.conf

and directory

/etc/pkg/foo

then the /etc/pkg/foo is matched and not removed.

If you want this fixed, just ping me, it's easy to add something like
"&& (....->name[namelen] == \0 or ...->name[namelen] == '/')", and
I'll fix it at both places.

O.

On Wed, May 4, 2011 at 06:20, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ondřej Surý wrote:
>
>> At the moment the only solution I see is what I have suggested - keep
>> ownership of whole tree up-to-the root for directories holding
>> conffiles and try to remove them at purge time...
>>
>> dpkg --remove php5-cli
>> # ownership kept for /., /etc, /etc/php5, /etc/php5/cli
>
> Yes, makes sense.
>
>> On Tue, May 3, 2011 at 01:05, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> If anyone interested in working on this has any questions, please feel
>>> free to let us know.
>>
>> I could work on that...
>
> That would be excellent!
>



-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/
[0001-Keep-parent-directories-for-directories-in-leftover-.patch (application/octet-stream, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Fri, 06 May 2011 04:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 06 May 2011 04:30:03 GMT) Full text and rfc822 format available.

Message #76 received at 316521@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Ondřej Surý <ondrej@debian.org>, 316521@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Fri, 6 May 2011 06:28:05 +0200
[Message part 1 (text/plain, inline)]
Hi!

On Wed, 2011-05-04 at 11:11:10 +0200, Ondřej Surý wrote:
> The attached patch keeps the directory in the <pkg>.list (aka add it
> to the leftover) if the children directory is found on the leftover
> list.

The problem is that the check is not correct, isdirectoryinuse (now
dir_is_used_by_others) checks for the directory being referenced by
other packages, and here we only care if it's owned by the package
being acted on.

> There could be a slight modification to keep /. in the list as well to
> be formally correct, but IMO it's not needed.

Right, and it actually needs to be ignored on removal or dpkg fails on
non dpkg native systems (or fake environments), where the last package
can be easily removed.

Anyway I'm attaching a modified version, but I've only build tested
it. If you could test it that'd be nice. It would be nice to have a
test case for our functional test-suite too. :)

  <http://git.debian.org/?p=dpkg/pkg-tests.git>

> Also I have found a small bug in the matching function
> hasdirectoryconffiles and I am inheriting it (since I don't think it's
> major)...
> 
> If there is a conffile named:
> 
> /etc/pkg/foobar/foo.conf
> 
> and directory
> 
> /etc/pkg/foo
> 
> then the /etc/pkg/foo is matched and not removed.
> 
> If you want this fixed, just ping me, it's easy to add something like
> "&& (....->name[namelen] == \0 or ...->name[namelen] == '/')", and
> I'll fix it at both places.

Ah nice catch! I've pushed a fix for this (commit
2c9a342dc4e1ad3e9e58ac89957b9068664d1930). Thanks!

regards,
guillem
[0001-dpkg-Keep-parent-directories-of-directories-kept-dur.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Fri, 06 May 2011 06:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@sury.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 06 May 2011 06:03:03 GMT) Full text and rfc822 format available.

Message #81 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@sury.org>
To: Guillem Jover <guillem@debian.org>
Cc: "316521@bugs.debian.org" <316521@bugs.debian.org>, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Fri, 6 May 2011 08:01:14 +0200
On 6.5.2011, at 6:28, Guillem Jover <guillem@debian.org> wrote:

> Hi!
> 
> On Wed, 2011-05-04 at 11:11:10 +0200, Ondřej Surý wrote:
>> The attached patch keeps the directory in the <pkg>.list (aka add it
>> to the leftover) if the children directory is found on the leftover
>> list.
> 
> The problem is that the check is not correct, isdirectoryinuse (now
> dir_is_used_by_others) checks for the directory being referenced by
> other packages, and here we only care if it's owned by the package
> being acted on.

Right. But you only care in the case if the directory is used by others, because only in this case it's not added to leftover list if not removed, so you can save the check time for every directory used only by the package itself.

But although I think my patch was correct:-), I also think your patch is more readable for future readers, so no hard feelings.

>> There could be a slight modification to keep /. in the list as well to
>> be formally correct, but IMO it's not needed.
> 
> Right, and it actually needs to be ignored on removal or dpkg fails on
> non dpkg native systems (or fake environments), where the last package
> can be easily removed.
> 
> Anyway I'm attaching a modified version, but I've only build tested
> it. If you could test it that'd be nice. It would be nice to have a
> test case for our functional test-suite too. :)
> 
>  <http://git.debian.org/?p=dpkg/pkg-tests.git>

I'll do that over weekend.

>> If you want this fixed, just ping me, it's easy to add something like
>> "&& (....->name[namelen] == \0 or ...->name[namelen] == '/')", and
>> I'll fix it at both places.
> 
> Ah nice catch! I've pushed a fix for this (commit
> 2c9a342dc4e1ad3e9e58ac89957b9068664d1930). Thanks!

Cool. Also you're right that you don't need to check for \0 in dir_is_used_by_pkg, but I am unsure if you can do the same check (/foo not matching /foo in other package) is dir_is_used_by_others. In fact I think it's wrong... If two packages contains /var/foo/bar/ and both depend on this directory to run (f.e. creating files there on the first run or only when issuing 'dump' command, etc...), you will remove it on first package removal if it's empty thus breaking the second package.

O.
P.S.: Typed on iPhone, so excuse the typos.



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Fri, 06 May 2011 06:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 06 May 2011 06:21:03 GMT) Full text and rfc822 format available.

Message #86 received at 316521@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ondřej Surý <ondrej@sury.org>, 316521@bugs.debian.org
Cc: Guillem Jover <guillem@debian.org>, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Fri, 6 May 2011 08:16:43 +0200
On Fri, 06 May 2011, Ondřej Surý wrote:
> >> If you want this fixed, just ping me, it's easy to add something like
> >> "&& (....->name[namelen] == \0 or ...->name[namelen] == '/')", and
> >> I'll fix it at both places.
> > 
> > Ah nice catch! I've pushed a fix for this (commit
> > 2c9a342dc4e1ad3e9e58ac89957b9068664d1930). Thanks!
> 
> Cool. Also you're right that you don't need to check for \0 in
> dir_is_used_by_pkg, but I am unsure if you can do the same check (/foo
> not matching /foo in other package) is dir_is_used_by_others. In fact I
> think it's wrong... If two packages contains /var/foo/bar/ and both
> depend on this directory to run (f.e. creating files there on the first
> run or only when issuing 'dump' command, etc...), you will remove it on
> first package removal if it's empty thus breaking the second package.

dir_is_used_by_others does not check the filename in the same way, in fact
it iterates the list of packages associated to the namemode.

So the problem you mention doesn't exist at all.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Fri, 06 May 2011 12:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@sury.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 06 May 2011 12:57:04 GMT) Full text and rfc822 format available.

Message #91 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@sury.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 316521@bugs.debian.org, Guillem Jover <guillem@debian.org>, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Fri, 6 May 2011 14:53:14 +0200
2011/5/6 Raphael Hertzog <hertzog@debian.org>:
> On Fri, 06 May 2011, Ondřej Surý wrote:
>> >> If you want this fixed, just ping me, it's easy to add something like
>> >> "&& (....->name[namelen] == \0 or ...->name[namelen] == '/')", and
>> >> I'll fix it at both places.
>> >
>> > Ah nice catch! I've pushed a fix for this (commit
>> > 2c9a342dc4e1ad3e9e58ac89957b9068664d1930). Thanks!
>>
>> Cool. Also you're right that you don't need to check for \0 in
>> dir_is_used_by_pkg, but I am unsure if you can do the same check (/foo
>> not matching /foo in other package) is dir_is_used_by_others. In fact I
>> think it's wrong... If two packages contains /var/foo/bar/ and both
>> depend on this directory to run (f.e. creating files there on the first
>> run or only when issuing 'dump' command, etc...), you will remove it on
>> first package removal if it's empty thus breaking the second package.
>
> dir_is_used_by_others does not check the filename in the same way, in fact
> it iterates the list of packages associated to the namemode.
>
> So the problem you mention doesn't exist at all.

That's what happens if you try to use iPhone as full functional
device. I checked only the mentioned commit and mixed up
dir_has_conffiles and dir_is_used_by_others, because I have remembered
that I found it on two places.

And you're right and the problem doesn't exist in either. Sorry for
not checking harder :).

O.
-- 
Ondřej Surý <ondrej@sury.org>




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Wed, 11 May 2011 09:30:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 11 May 2011 09:30:10 GMT) Full text and rfc822 format available.

Message #96 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 316521@bugs.debian.org, Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Wed, 11 May 2011 11:28:20 +0200
[Message part 1 (text/plain, inline)]
Hi Guillem,

your patch doesn't fix the problem, and even introduces more problems,
because as it is written it leaves all directories which have
conffiles on the disk.

This section:

static void
removal_bulk_remove_files(struct pkginfo *pkg)
{
[...]
    if (namenode->flags & fnnf_old_conff) {
      push_leftover(&leftover,namenode);
      continue;
    }

causes every conffile to be added to leftover list triggering
dir_is_used_by_pkg for every parent directory of the conffile.

However if you put back the logic to run the dir_is_used_by_pkg only
if the file is used by others then it works correctly because the
directory gets removed by last package owning the directory. (0001
does that and works)

Another option would be to split the loops and add conffiles to
leftover list after the first run (something like in the second
attached patch).

> It would be nice to have a
> test case for our functional test-suite too. :)
>
>  <http://git.debian.org/?p=dpkg/pkg-tests.git>

Test case is attached.

O.


2011/5/6 Guillem Jover <guillem@debian.org>:
> Hi!
>
> On Wed, 2011-05-04 at 11:11:10 +0200, Ondřej Surý wrote:
>> The attached patch keeps the directory in the <pkg>.list (aka add it
>> to the leftover) if the children directory is found on the leftover
>> list.
>
> The problem is that the check is not correct, isdirectoryinuse (now
> dir_is_used_by_others) checks for the directory being referenced by
> other packages, and here we only care if it's owned by the package
> being acted on.
>
>> There could be a slight modification to keep /. in the list as well to
>> be formally correct, but IMO it's not needed.
>
> Right, and it actually needs to be ignored on removal or dpkg fails on
> non dpkg native systems (or fake environments), where the last package
> can be easily removed.
>
> Anyway I'm attaching a modified version, but I've only build tested
> it. If you could test it that'd be nice. It would be nice to have a
> test case for our functional test-suite too. :)
>
>  <http://git.debian.org/?p=dpkg/pkg-tests.git>
>
>> Also I have found a small bug in the matching function
>> hasdirectoryconffiles and I am inheriting it (since I don't think it's
>> major)...
>>
>> If there is a conffile named:
>>
>> /etc/pkg/foobar/foo.conf
>>
>> and directory
>>
>> /etc/pkg/foo
>>
>> then the /etc/pkg/foo is matched and not removed.
>>
>> If you want this fixed, just ping me, it's easy to add something like
>> "&& (....->name[namelen] == \0 or ...->name[namelen] == '/')", and
>> I'll fix it at both places.
>
> Ah nice catch! I've pushed a fix for this (commit
> 2c9a342dc4e1ad3e9e58ac89957b9068664d1930). Thanks!
>
> regards,
> guillem
>



-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/
[0001-Keep-parent-directories-in-the-leftover-list-if-the-.patch (text/x-patch, attachment)]
[0002-Add-conffiles-in-second-loop.patch (text/x-patch, attachment)]
[0001-Add-test-for-leftover-dirs-for-directories-containin.patch (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Thu, 12 May 2011 01:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 May 2011 01:39:03 GMT) Full text and rfc822 format available.

Message #101 received at 316521@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Ondřej Surý <ondrej@debian.org>, 316521@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Thu, 12 May 2011 03:37:00 +0200
Hi!

Thanks for the test-case, I've commited it as t-dir-leftover-deadlock,
and added a new t-dir-leftover-parents which is what I thought you
were trying to solve initially, given your bug report. So I think these
two issues should be detangled, and I'll be applying my revised patch
to fix the -parents case. For a fix for t-dir-leftover-deadlock then
it's not as straight forward as it might seem and I'd recommend reading
Raphaël's summary in:

  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316521#39>

On Wed, 2011-05-11 at 11:28:20 +0200, Ondřej Surý wrote:
> your patch doesn't fix the problem, and even introduces more problems,
> because as it is written it leaves all directories which have
> conffiles on the disk.

That's not correct, it behaves as it should be, but that's not changed
by my patch, that's the current behaviour already. If a directory
contains conffiles then they need to be tracked so that they can be
removed on purge.

> This section:
> 
> static void
> removal_bulk_remove_files(struct pkginfo *pkg)
> {
> [...]
>     if (namenode->flags & fnnf_old_conff) {
>       push_leftover(&leftover,namenode);
>       continue;
>     }
> 
> causes every conffile to be added to leftover list triggering
> dir_is_used_by_pkg for every parent directory of the conffile.

No, that's already handled by dir_has_conffiles() currently. It keeps
any directory containing a conffile either directly or as part of any
subdrirectories. The only case were dir_is_used_by_pkg() will trigger
is when a package S has a shared directory hierarchy:

  /a/b/

And another package C has a not shared leaf directory containing
a configuration file (or any other maintainer script or run time
generated files):

  /a/b/c/file

When we remove C, dpkg will try to rmdir /a/b/c, because it's not
shared with S, but it will fail because it's not empty. Then currently
it will lose track of /a/b and /a because they are shared. When S gets
purged dpkg loses track of /a/b and /a, and then when C is purged it
only tries to remove /a/b/c, but not the other two.

That's because dir_is_used_by_pkg() needs one of its child directories
to be already tracked, or it will not match, and if any of its childs
is tracked then we *must* track the parent, or we might lose track of
it.

> However if you put back the logic to run the dir_is_used_by_pkg only
> if the file is used by others then it works correctly because the
> directory gets removed by last package owning the directory. (0001
> does that and works)

That's not possible, both your initial patch and my revision should
behave equally with the current code, my objection to your initial
patch was that it's not future proof, and it has a wrong assumption
on the check location. Anyway just to make extra sure, I've tested
your version (0001) and it only fixes t-dir-leftover-parents, as
expected, and not the -deadlock one.

> Another option would be to split the loops and add conffiles to
> leftover list after the first run (something like in the second
> attached patch).

And tested this one (0002) too and it also only fixes
t-dir-leftover-parents, and not t-dir-leftover-deadlock. In addition
it changes the order of the .list file, and in general I don't really
see what it's trying to solve, the issues at hand are related to
configuration files not conffiles.

> > It would be nice to have a
> > test case for our functional test-suite too. :)
> >
> >  <http://git.debian.org/?p=dpkg/pkg-tests.git>
> 
> Test case is attached.

The empty directories were missing, I've added them with a hidden file
so that git preserves them.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Thu, 12 May 2011 09:00:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 May 2011 09:00:14 GMT) Full text and rfc822 format available.

Message #106 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 316521@bugs.debian.org
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Thu, 12 May 2011 10:57:25 +0200
[Message part 1 (text/plain, inline)]
Hi,

sorry I wasn't clear in my previous mail. I'll attach test cases and
logs this time.

2011/5/12 Guillem Jover <guillem@debian.org>:
> Hi!
>
> Thanks for the test-case, I've commited it as t-dir-leftover-deadlock,
> and added a new t-dir-leftover-parents which is what I thought you
> were trying to solve initially, given your bug report.

Well, it seems to me that the php5-common/php5-cli problem is
combination of both issues, hence the confusion on my part.

> So I think these two issues should be detangled,

I agree, the two test cases helped :). And the deadlock case is really
not solved by any of our patches.

> and I'll be applying my revised patch to fix the -parents case.

I hope I can convince you that your patch as-is causes a regression.

Here's the log of dpkg --purge php5-common (after removing php5-cli,
php5-common):

D001000: dir_has_conffiles '/etc/php5/conf.d' (from php5-common)
D001000: dir_has_conffiles no
D001000: dir_is_used_by_pkg '/etc/php5/conf.d' (by php5-common)
D001000: dir_is_used_by_pkg considering /etc/php5/conf.d/pdo.ini ...
D001000: dir_has_conffiles '/etc/php5' (from php5-common)
D001000: dir_has_conffiles no
D001000: dir_is_used_by_pkg '/etc/php5' (by php5-common)
D001000: dir_is_used_by_pkg considering /etc/php5/conf.d ...
D001000: dir_has_conffiles '/etc/cron.d' (from php5-common)
D001000: dir_has_conffiles no
D001000: dir_is_used_by_pkg '/etc/cron.d' (by php5-common)
D001000: dir_is_used_by_pkg considering /etc/cron.d/php5 ...
D001000: dir_has_conffiles '/etc' (from php5-common)
D001000: dir_has_conffiles no
D001000: dir_is_used_by_pkg '/etc' (by php5-common)
D001000: dir_is_used_by_pkg considering /etc/cron.d ...

And the /etc/php5/conf.d is left on the system.

You can find the test case attached which works OK with current
unstable dpkg and fails with git version+your patch.

> For a fix for t-dir-leftover-deadlock then
> it's not as straight forward as it might seem and I'd recommend reading
> Raphaël's summary in:
>
>  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316521#39>

I see, you're right. After reading the summary and the original bug
reports I see only two solutions to this problem:

a) teach dpkg to remove parent directories not used by other packages
on purge (slight modification of Raphael's case one)

b) write some logic to dpkg-maintscript-helper which would allow the
maintainers to either specify directories to purge in postrm, or
directories to keep in the list on remove.

I don't think it's feasible to search the directories for files not
used by other packages, this would make dpkg very slow in corner cases
(many files in many directories).

( c) would be the simplest solution - just keep directories used by
more packages in the list and remove them on purge, but that's very
ugly)

BTW it's not only "configuration files", but "logfiles" as well, as
all other files not in the packages and created either by maintainer
scripts or by package itself.

> On Wed, 2011-05-11 at 11:28:20 +0200, Ondřej Surý wrote:
>> your patch doesn't fix the problem, and even introduces more problems,
>> because as it is written it leaves all directories which have
>> conffiles on the disk.
>
> That's not correct, it behaves as it should be, but that's not changed
> by my patch, that's the current behaviour already. If a directory
> contains conffiles then they need to be tracked so that they can be
> removed on purge.

See above. The problem is that the directory is not removed on purge.
The 0002 patch applied on top of yours fixes the test case.

Ondrej
-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/
[0001-Add-test-for-leftover-directories-containing-conffil.patch (text/x-patch, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Thu, 12 May 2011 12:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 May 2011 12:27:03 GMT) Full text and rfc822 format available.

Message #111 received at 316521@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Ondřej Surý <ondrej@debian.org>, 316521@bugs.debian.org
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Thu, 12 May 2011 14:24:44 +0200
Hi!

On Thu, 2011-05-12 at 10:57:25 +0200, Ondřej Surý wrote:
> sorry I wasn't clear in my previous mail. I'll attach test cases and
> logs this time.

Thanks, that makes it more clear yes. :)

> Well, it seems to me that the php5-common/php5-cli problem is
> combination of both issues, hence the confusion on my part.

Ah, ok.

> 2011/5/12 Guillem Jover <guillem@debian.org>:
> > and I'll be applying my revised patch to fix the -parents case.
> 
> I hope I can convince you that your patch as-is causes a regression.
> 
> Here's the log of dpkg --purge php5-common (after removing php5-cli,
> php5-common):

[...]

> And the /etc/php5/conf.d is left on the system.
> 
> You can find the test case attached which works OK with current
> unstable dpkg and fails with git version+your patch.

Ah! Now I see, and indeed it does. So the problem here is that
removal_bulk_remove_configfiles() is buggy as it does not remove the
conffiles from the package files list when it unlinks them, and they
linger around when we are removing the leftover directories on purge.
On entry removal_bulk_remove_leftover_dirs() should really only
contain directories (or symlinks to directories) nothing else. I'll
fix that up.

> > For a fix for t-dir-leftover-deadlock then
> > it's not as straight forward as it might seem and I'd recommend reading
> > Raphaël's summary in:
> >
> >  <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316521#39>
> 
> I see, you're right. After reading the summary and the original bug
> reports I see only two solutions to this problem:
> 
> a) teach dpkg to remove parent directories not used by other packages
> on purge (slight modification of Raphael's case one)

> b) write some logic to dpkg-maintscript-helper which would allow the
> maintainers to either specify directories to purge in postrm, or
> directories to keep in the list on remove.
> 
> I don't think it's feasible to search the directories for files not
> used by other packages, this would make dpkg very slow in corner cases
> (many files in many directories).

While I don't think it might cause a huge degradation, I agree though
it's not really the correct solution.

> ( c) would be the simplest solution - just keep directories used by
> more packages in the list and remove them on purge, but that's very
> ugly)

The correct solution is to teach dpkg about external files.

> BTW it's not only "configuration files", but "logfiles" as well, as
> all other files not in the packages and created either by maintainer
> scripts or by package itself.

Sure, I explicitly wrote something along those lines for the
test-case. :)

> > On Wed, 2011-05-11 at 11:28:20 +0200, Ondřej Surý wrote:
> >> your patch doesn't fix the problem, and even introduces more problems,
> >> because as it is written it leaves all directories which have
> >> conffiles on the disk.
> >
> > That's not correct, it behaves as it should be, but that's not changed
> > by my patch, that's the current behaviour already. If a directory
> > contains conffiles then they need to be tracked so that they can be
> > removed on purge.
> 
> See above. The problem is that the directory is not removed on purge.
> The 0002 patch applied on top of yours fixes the test case.

You are absolutely right, sorry I din't see it before.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Thu, 12 May 2011 14:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 May 2011 14:57:03 GMT) Full text and rfc822 format available.

Message #116 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 316521@bugs.debian.org
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Thu, 12 May 2011 16:53:24 +0200
[Message part 1 (text/plain, inline)]
Hi,

2011/5/12 Guillem Jover <guillem@debian.org>:
>> You can find the test case attached which works OK with current
>> unstable dpkg and fails with git version+your patch.
>
> Ah! Now I see, and indeed it does. So the problem here is that
> removal_bulk_remove_configfiles() is buggy as it does not remove the
> conffiles from the package files list when it unlinks them, and they
> linger around when we are removing the leftover directories on purge.
> On entry removal_bulk_remove_leftover_dirs() should really only
> contain directories (or symlinks to directories) nothing else. I'll
> fix that up.

Cool :).

> You are absolutely right, sorry I didn't see it before.

No problem at all. I am glad that we found a new bug in dpkg in the
process. And we have one more test case, which always helps.

>> I see, you're right. After reading the summary and the original bug
>> reports I see only two solutions to this problem:
>>
>> a) teach dpkg to remove parent directories not used by other packages
>> on purge (slight modification of Raphael's case one)
>
>> b) write some logic to dpkg-maintscript-helper which would allow the
>> maintainers to either specify directories to purge in postrm, or
>> directories to keep in the list on remove.
>>
>> I don't think it's feasible to search the directories for files not
>> used by other packages, this would make dpkg very slow in corner cases
>> (many files in many directories).
>
> While I don't think it might cause a huge degradation, I agree though
> it's not really the correct solution.
>
>> ( c) would be the simplest solution - just keep directories used by
>> more packages in the list and remove them on purge, but that's very
>> ugly)
>
> The correct solution is to teach dpkg about external files.

But that's a long term solution I guess... What about doing b) in meantime.

a) it would be optional for maintainers to use in postinst... f.e. I could add:

dpkg-maintscript-helper purge_dir /etc/php5/conf.d to php5-common postinst
and
dpkg-maintscript-helper purge_dir /etc/php5/cli to php5-cli postinst

b) it could be integrated with ucf (ie. ucf would call the script)

That would solve most cases.

[...meanwhile...]

I have implemented the command. It doesn't go with corresponding
manpage section and probably needs some polishing, but it works in my
case...

In fact, I needed to add

dpkg-maintscript-helper purge_dir $phpini

only to php5-cli.postrm to cleanup the cruft.

O.
-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/
[0001-Add-purge_dir-command-to-dpkg-maintscript-helper.patch (text/x-patch, attachment)]

Disconnected #454694 from all other report(s). Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 16 May 2011 03:21:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Mon, 16 May 2011 12:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 16 May 2011 12:45:04 GMT) Full text and rfc822 format available.

Message #123 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Guillem Jover <guillem@debian.org>
Cc: 316521@bugs.debian.org
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Mon, 16 May 2011 14:43:10 +0200
(small) ping with question...

Are you going to consider implementing purge_dir to
dpkg-maintscript-helper or should I do it directly in
php5-<sapi>.postinst scripts? (Both options are OK for me.)

O.
-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Tue, 17 May 2011 12:23:51 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 17 May 2011 12:24:35 GMT) Full text and rfc822 format available.

Message #128 received at 316521@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ondřej Surý <ondrej@debian.org>, 316521@bugs.debian.org
Cc: Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Mon, 16 May 2011 21:51:30 +0200
Hi,

On Mon, 16 May 2011, Ondřej Surý wrote:
> (small) ping with question...
> 
> Are you going to consider implementing purge_dir to
> dpkg-maintscript-helper or should I do it directly in
> php5-<sapi>.postinst scripts? (Both options are OK for me.)

I'm definitely interested into providing a standardized
solution with dpkg-maintscript-helper until dpkg can
support this natively.

I'm just not sure what the correct solution is. Instead of purge_dir maybe
the right answer is "manage-manual-conffile" and/or
"manage-manual-file". And it would drop the file on removal/purge and try
to remove the parent directories if they are no longer owned.

For now, the "preinst/prerm/postinst" would be a no-op but the postrm
would do the removal. Later when we can tell dpkg that the package
installed some manual files, the registration would happen in postinst
and in the other scripts the command would become a no-op since
dpkg itself would do the removal.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Wed, 18 May 2011 08:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ondřej Surý <ondrej@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 18 May 2011 08:30:03 GMT) Full text and rfc822 format available.

Message #133 received at 316521@bugs.debian.org (full text, mbox):

From: Ondřej Surý <ondrej@debian.org>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 316521@bugs.debian.org, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Wed, 18 May 2011 10:25:44 +0200
Hi,

2011/5/16 Raphael Hertzog <hertzog@debian.org>:
> Hi,
>
> On Mon, 16 May 2011, Ondřej Surý wrote:
>> (small) ping with question...
>>
>> Are you going to consider implementing purge_dir to
>> dpkg-maintscript-helper or should I do it directly in
>> php5-<sapi>.postinst scripts? (Both options are OK for me.)
>
> I'm definitely interested into providing a standardized
> solution with dpkg-maintscript-helper until dpkg can
> support this natively.
>
> I'm just not sure what the correct solution is. Instead of purge_dir maybe
> the right answer is "manage-manual-conffile" and/or
> "manage-manual-file". And it would drop the file on removal/purge and try
> to remove the parent directories if they are no longer owned.
>
> For now, the "preinst/prerm/postinst" would be a no-op but the postrm
> would do the removal. Later when we can tell dpkg that the package
> installed some manual files, the registration would happen in postinst
> and in the other scripts the command would become a no-op since
> dpkg itself would do the removal.

Sounds good. The only problem I see is that it could be "files" (as in
/var/log/<package>), so maybe a pattern is needed?

Something like:

dpkg-maintscript-helper manage-manual-files /var/log/<package>/*.log*

Or maybe I am overcomplicating stuff and we already know how to handle
logfiles and this is really for low-number of files.

Anyway I think that my patch would work just like that, just rename
the purge_dir to what you like :)

O.
-- 
Ondřej Surý <ondrej@sury.org>
http://blog.rfc1925.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Thu, 21 Jul 2011 08:39:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 21 Jul 2011 08:39:13 GMT) Full text and rfc822 format available.

Message #138 received at 316521@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Ondřej Surý <ondrej@debian.org>, 316521@bugs.debian.org
Cc: Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories when packages install conffiles to subsubdirectories of /etc
Date: Thu, 21 Jul 2011 10:37:34 +0200
Hi Ondrej,

On Wed, 18 May 2011, Ondřej Surý wrote:
> > I'm just not sure what the correct solution is. Instead of purge_dir maybe
> > the right answer is "manage-manual-conffile" and/or
> > "manage-manual-file". And it would drop the file on removal/purge and try
> > to remove the parent directories if they are no longer owned.
> >
> > For now, the "preinst/prerm/postinst" would be a no-op but the postrm
> > would do the removal. Later when we can tell dpkg that the package
> > installed some manual files, the registration would happen in postinst
> > and in the other scripts the command would become a no-op since
> > dpkg itself would do the removal.
> 
> Sounds good. The only problem I see is that it could be "files" (as in
> /var/log/<package>), so maybe a pattern is needed?
> 
> Something like:
> dpkg-maintscript-helper manage-manual-files /var/log/<package>/*.log*
> 
> Or maybe I am overcomplicating stuff and we already know how to handle
> logfiles and this is really for low-number of files.
> 
> Anyway I think that my patch would work just like that, just rename
> the purge_dir to what you like :)

Thinking a bit more about it, I believe it's more reasonable to go
with a "purge_related_files" command. It would indeed accept several
files and/or directories.

Patterns should be expanded by the shell so that the function itself
doesn't have to deal with patterns.

You patch is not really ready for this, I'm commenting below.

On Thu, 12 May 2011, Ondřej Surý wrote:
> I have implemented the command. It doesn't go with corresponding
> manpage section and probably needs some polishing, but it works in my
> case...

Yeah, it would be nice if you could finish the work including the required
documentation. See my other comments below:

> In fact, I needed to add
> dpkg-maintscript-helper purge_dir $phpini
> only to php5-cli.postrm to cleanup the cruft.

All dpkg-maintscript-helper commands must support being called in all
maintainer scripts and must ensure they are a no-op in maintainer scripts
where nothing should be done.

This is currently not the case for your new command.

For instance dh_installdeb makes use of this characteristic to generate
the same snippet in all maintainer scripts based on what the packager
provided in debian/package.maintscript.

> +purge_dir() {

Oviously renamed to purge_related_files. 

> +	local DIRECTORY="$1"
> +	local PACKAGE="$2"
> +	if [ "${PACKAGE}" = "--" -o -z "${PACKAGE}" ]; then
> +		PACKAGE="${DPKG_MAINTSCRIPT_PACKAGE}"
> +	fi

So we need to accept multiple parameters here. It probably means that we
should get rid of the PACKAGE parameter and just hope that
DPKG_MAINTSCRIPT_PACKAGE is set.

And the algorithm should be something like this:
for f in $files; do
    if [ -L $f ] || [ ! -d $f ]; then
	rm $f
	# add $(dirname $f) to a list of directories
    else
	# add $f to a list of directories
    fi
done

for d in $dirlist; do
    purge_dir $dir # what your current function does
done

I'm not sure what's the best way to handle the list of directories
to correctly deal with path that includes spaces... possibly a temporary
file.

> +	while [ "$DIRECTORY" != "/" ]; do
> +
> +		local OWNED_BY="$(dpkg-query -S "${DIRECTORY}" 2>/dev/null | cut -f 1 -d :)"
> +
> +		if [ -z "${OWNED_BY}" -o "${OWNED_BY}" = "${PACKAGE}" ]; then
> +			[ -d "${DIRECTORY}" ] && \
> +			    rmdir --ignore-fail-on-non-empty "${DIRECTORY}"
> +
> +			# Directory was not removed
> +			if [ -d "${DIRECTORY}" ]; then
> +				echo "Unable to remove ${DIRECTORY}: directory not empty"
> +				return 1

We don't want the postrm to fail just because of this. Thus return 0.

> +			else
> +				DIRECTORY="$(dirname "${DIRECTORY}")"
> +				purge_dir "${DIRECTORY}" "${PACKAGE}"
> +				return $?

Thus it doesn't bring anything to forward the return value here.

> +			fi
> +		else
> +			debug "Preserving ${DIRECTORY}; still owned by ${#OWNED_BY} package(s)"

Why ${#OWNED_BY} ? The string length is not equal to the number of
packages...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Thu, 08 Mar 2012 11:50:52 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Beckmann <debian@abeckmann.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 08 Mar 2012 11:50:52 GMT) Full text and rfc822 format available.

Message #143 received at 316521@bugs.debian.org (full text, mbox):

From: Andreas Beckmann <debian@abeckmann.de>
To: Raphael Hertzog <hertzog@debian.org>
Cc: Ondřej Surý <ondrej@debian.org>, 316521@bugs.debian.org, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Date: Thu, 8 Mar 2012 12:24:37 +0100
[Message part 1 (text/plain, inline)]
Hi,

(regarding the previous posts in this thread:)
while having a dpkg-maintscript-helper subcommand that cleans up files during 
purge may be nice to simplify writing maintainer scripts, I think the removal 
of (parent-) directories should stay dpkg's job.

(regarding the original problem:)
I'm seeing a lot of owned directories remaining in the piuparts tests for sid 
(they are treated as error for sid and warning for other distributions):
http://piuparts.debian.org/sid/owned_files_by_many_packages_error.html
http://piuparts.debian.org/sid/owned_files_after_purge_error.html

I tried to create a minimal package that triggers the behaviour. Looks like it 
is related to directories owned by multiple packages and their removal order.

A minimal example package is attached: extract, debuild, and you get 2 .debs:
foo and foobar both ship the empty /var/lib/foobar directory
foobar.postinst configure creates a file there
foobar.postrm purge cleans up the file created in the postinst
foo.postrm purge cleans up a nonexisting file there

# dpkg -i foo_1_all.deb foobar_1_all.deb
Selecting previously unselected package foo.
(Reading database ... 13543 files and directories currently installed.)
Unpacking foo (from foo_1_all.deb) ...
Selecting previously unselected package foobar.
Unpacking foobar (from foobar_1_all.deb) ...
Setting up foo (1) ...
Setting up foobar (1) ...

# dpkg -S $(find /var/lib/foobar)
foo, foobar: /var/lib/foobar
dpkg-query: no path found matching pattern /var/lib/foobar/state.

# dpkg --remove foo foobar
(Reading database ... 13550 files and directories currently installed.)
Removing foo ...
Removing foobar ...

# dpkg -S $(find /var/lib/foobar)
foobar: /var/lib/foobar
dpkg-query: no path found matching pattern /var/lib/foobar/state.

# dpkg --purge foo foobar
(Reading database ... 13544 files and directories currently installed.)
Removing foo ...
Purging configuration files for foo ...
Removing foobar ...
Purging configuration files for foobar ...

# find /var/lib/foobar
find: `/var/lib/foobar': No such file or directory

### OK this went fine, let's permute some arguments

# dpkg -i foobar_1_all.deb foo_1_all.deb
Selecting previously unselected package foobar.
(Reading database ... 13543 files and directories currently installed.)
Unpacking foobar (from foobar_1_all.deb) ...
Selecting previously unselected package foo.
Unpacking foo (from foo_1_all.deb) ...
Setting up foobar (1) ...
Setting up foo (1) ...

# dpkg -S $(find /var/lib/foobar)
foo, foobar: /var/lib/foobar
dpkg-query: no path found matching pattern /var/lib/foobar/state.

# dpkg --remove foobar foo
(Reading database ... 13550 files and directories currently installed.)
Removing foobar ...
Removing foo ...

# dpkg -S $(find /var/lib/foobar)
foo: /var/lib/foobar
dpkg-query: no path found matching pattern /var/lib/foobar/state.

# dpkg --purge foo foobar
(Reading database ... 13544 files and directories currently installed.)
Removing foo ...
Purging configuration files for foo ...
dpkg: warning: while removing foo, directory '/var/lib/foobar' not empty so 
not removed.
Removing foobar ...
Purging configuration files for foobar ...

# find /var/lib/foobar
/var/lib/foobar

# dpkg -S $(find /var/lib/foobar)
dpkg-query: no path found matching pattern /var/lib/foobar.


The problem seems to be which package keeps ownership of a shared directory in 
the case of removal. As it is now, this stays with the package to be removed 
last. But that one is not necessarily the one purged last.

IMO, during directory removal two cases are to be distinguished:
a) really empty directories (that either do not exist any more or rmdir on the 
   directory would succeed - not empty in the sense 'dpkg knows no file/dir 
   inside this directory'):
   these can be unregistered during REMOVE (aka removed from the file list of 
   the package being removed) and removed from the filesystem if the reference 
   count drops to 0
b) not empty directories (rmdir would fail regardless of dpkg knowing any file 
   below this path):
   these should be kept during REMOVE and should only be removed during PURGE
   (unregistered from the file list and eventually rmdir-ed, but a diagnostic   
   that removal failed should only be emitted after 'postrm purge' was run, 
   the reference count dropped to 0 but the directory still can't be removed)
For packages without postrm and with no conffiles (where REMOVE implies PURGE) 
this would not change the current behavior.

That way every package that has shipped some directory and cleans up something 
in there during postrm purge can be sure that it still owns the directory and 
dpkg will clean this up afterwards. If the directory was really empty earlier 
and dpkg decided to unregister (and possibly rmdir) it, there was also 
nothing left for the postrm purge to clean up. (And if files to be cleaned up 
during purge appear *after* the package was removed, this is a serious error 
elsewhere.)

I would really like to see this fixed for wheezy.


Andreas
[foobar_1.tar.gz (application/x-tgz, attachment)]

Removed indication that bug 316521 blocks 566853 Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 04:57:04 GMT) Full text and rfc822 format available.

Added tag(s) patch. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 04:57:12 GMT) Full text and rfc822 format available.

Removed tag(s) patch. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 05:18:03 GMT) Full text and rfc822 format available.

No longer marked as found in versions 1.10.9. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 05:18:06 GMT) Full text and rfc822 format available.

No longer marked as found in versions 1.10.28 and dpkg/1.10.28. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 05:18:08 GMT) Full text and rfc822 format available.

Marked as found in versions dpkg/1.10.9. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 05:18:09 GMT) Full text and rfc822 format available.

Marked as found in versions dpkg/1.10.28. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 05:18:11 GMT) Full text and rfc822 format available.

Merged 316521 348133 538429 625241 664822 Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Mon, 30 Apr 2012 05:18:12 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Fri, 13 Jul 2012 10:15:18 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 13 Jul 2012 10:15:22 GMT) Full text and rfc822 format available.

Message #164 received at 316521@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Andreas Beckmann <debian@abeckmann.de>, 316521@bugs.debian.org
Cc: Ondřej Surý <ondrej@debian.org>, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Date: Fri, 13 Jul 2012 12:04:30 +0200
[Message part 1 (text/plain, inline)]
Hi,

On Thu, 08 Mar 2012, Andreas Beckmann wrote:
> (regarding the original problem:)
> I'm seeing a lot of owned directories remaining in the piuparts tests for sid 
> (they are treated as error for sid and warning for other distributions):
> http://piuparts.debian.org/sid/owned_files_by_many_packages_error.html
> http://piuparts.debian.org/sid/owned_files_after_purge_error.html
> 
> I tried to create a minimal package that triggers the behaviour. Looks
> like it is related to directories owned by multiple packages and their
> removal order.

Basically, this is a variant of the test case "t-dir-leftover-deadlock":
http://anonscm.debian.org/gitweb/?p=dpkg/pkg-tests.git;a=tree;f=t-dir-leftover-deadlock;h=604270fa0caa72f31e5e1d73ec0f6fa02bd84f91;hb=master

And your analysis is correct.

We know a solution to the problem which is basically to not forget about
directories shared with other packages. But this approach leads us to 
keep ownership of lots of directories which are not really needed.

But the more I think about it, the more I'm convinced that it's
the least evil solution until we have a way to register arbitrary files in
dpkg. (I don't really like the complexity of the dpkg-maintscript-helper
snippet we discussed)

I would suggest to go with the attached patch which imposes just a
supplementary restriction. It will only remember shared directories
if the package has a postrm script (and thus has a chance to do something
during purge).

I believe this would make a good enough compromise. The number of useless
directory ownerships is much less problematic than the failure to properly
cleanup.

Another restriction which I did not implement but that we could implement
is that we can safely forget about directories which are shared but which
are empty. (But it would not make a huge difference because I don't know
of many shared directories that stay empty)

Cheers,

PS: In the attached patch, I wondered whether it was best to duplicate
foundpostrm or to modify the prototype of removal_bulk_remove_files()
so that removal_bulk() could forward it (since it already computes it).
Since boolean parameter are best avoided I opted to duplicate it.
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
[0001-dpkg-do-not-forget-about-shared-directories-if-we-ha.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Mon, 16 Jul 2012 11:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Beckmann <debian@abeckmann.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 16 Jul 2012 11:45:03 GMT) Full text and rfc822 format available.

Message #169 received at 316521@bugs.debian.org (full text, mbox):

From: Andreas Beckmann <debian@abeckmann.de>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 316521@bugs.debian.org, Ondřej Surý <ondrej@debian.org>, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Date: Mon, 16 Jul 2012 13:34:38 +0200
On 2012-07-13 12:04, Raphael Hertzog wrote:
> I would suggest to go with the attached patch which imposes just a
> supplementary restriction. It will only remember shared directories
> if the package has a postrm script (and thus has a chance to do something
> during purge).

I'm now testing the patch in my piuparts instance on sid ...

Would there be a chance to get this applied in wheezy if it doesn't show
problems?


Andreas



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Tue, 17 Jul 2012 09:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 17 Jul 2012 09:12:03 GMT) Full text and rfc822 format available.

Message #174 received at 316521@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: Andreas Beckmann <debian@abeckmann.de>
Cc: 316521@bugs.debian.org, Ondřej Surý <ondrej@debian.org>, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Date: Tue, 17 Jul 2012 10:58:33 +0200
Hi,

On Mon, 16 Jul 2012, Andreas Beckmann wrote:
> Would there be a chance to get this applied in wheezy if it doesn't show
> problems?

First off, Guillem need to ack the patch. Then it's somewhat unlikely to
be accepted by the release managers. You can always ask them though.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#316521; Package dpkg. (Mon, 06 Aug 2012 09:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Beckmann <debian@abeckmann.de>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 06 Aug 2012 09:27:06 GMT) Full text and rfc822 format available.

Message #179 received at 316521@bugs.debian.org (full text, mbox):

From: Andreas Beckmann <debian@abeckmann.de>
To: Raphael Hertzog <hertzog@debian.org>
Cc: 316521@bugs.debian.org, Ondřej Surý <ondrej@debian.org>, Guillem Jover <guillem@debian.org>
Subject: Re: Bug#316521: dpkg: stale directories are not removed after 'postrm purge'
Date: Mon, 06 Aug 2012 11:24:25 +0200
On 2012-07-17 10:58, Raphael Hertzog wrote:
> Hi,
> 
> On Mon, 16 Jul 2012, Andreas Beckmann wrote:
>> Would there be a chance to get this applied in wheezy if it doesn't show
>> problems?
> 
> First off, Guillem need to ack the patch. Then it's somewhat unlikely to
> be accepted by the release managers. You can always ask them though.

I've been running this patch on my piuparts instance for some time now
and processed the full sid amd64 archive several times (with different
settings) without encountering any problems w.r.t the patched dpkg.
Also most of the stale leftover directories are now gone (the remaining
ones are from packages using but not shipping a certain directory, but
that's not dpkg's fault)


Andreas



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 11:32:16 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.