[Piuparts-devel] Unclear failure for asclock (left over files in /var)

[Colin Watson]

On Sat, Nov 28, 2009 at 10:04:30PM +0100, Guillem Jover wrote:
> On Sat, 2009-11-28 at 10:22:40 +0100, Holger Levsen wrote:
> > On Mittwoch, 25. November 2009, Helge Kreutzmann wrote:
> > > Package purging left files on system:
> > >   /var/cache/man/pt      not owned
> > >   /var/cache/man/pt/cat1         not owned
> > [...]
> > > Judging from this analyis, this looks like a false positive...
> > 
> > I think it is too, but I'm not entirely sure, so I would appreciate a comment 
> > from someone more familar with "man" then I am, that's why I've added d-qa@ 
> > to cc:
> > 
> > So far, piuparts has been ignoring left over files with the following 
> > patterns:
> > 
> >             "/var/cache/man/(.*)/index.db",
> >             "/var/cache/man/index.db",
> > 
> > (obviously, there are more :)
> > 
> > Looking at the failed piuparts logs, I see there are more with left over files 
> > in /var/cache/man/.*/cat? - should piuparts just ignore /var/cache/man? 
> > Comments welcome.
> 
> Ignoring /var/cache/man/ seems the most reasonable course of action to
> me. The man-db package is the one handling those databases, it just
> seems logical to me that it should be the one in charge of removing it
> when purged.

It makes sense for mandb to observe that a hierarchy of manual pages has
gone away entirely (e.g. no more /usr/share/man/pt) and remove the
corresponding database. Could somebody file a bug on man-db for this, or
reassign/clone an existing bug? I wasn't sure if there was already a bug
report for this so I haven't filed one myself.

Ignoring /var/cache/man seems fairly harmless in the meantime.

(man-db of course does remove /var/cache/man when it itself is purged,
but we could perhaps do better.)

-- 
Colin Watson                                       [cjwatson at debian.org]