Re: Bug#1290: manpage timestamps and stuff

[Ian Jackson <iwj10@cus.cam.ac.uk>]

Richard Kettlewell writes ("Re: Bug#1290: cached man pages"):
> Taken this out of debian-bugs because I wish to make a more general
> remark.
> 
> Are there other files which might get cached in this manner?

Probably.  Only the maintainer of the package doing the cacheing would
know.

> For example, I can imagine someone coming up with a script to cache
> DVI or Postscript versions of documentation supplied in TeX for
> arbitrary packages; changing all the packages which supply TeX
> documentation to support this would probably be a bad thing, and
> similarly I think making man pages special on a per-package basis
> should also be avoided if possible.

Quite.

> Alvar Bray writes:
> >We could make dpkg set the time on installed files to the
> >installation rather than the archive time. This will ensure that any
> >existing catman pages are rebuilt after a package install.  Im sure
> >lots of people like to see the creation (archive) dates rather than
> >installation dates on files though. Personally I dont care about
> >this. Normally people use these dates for version comparisons
> >etc. they could use md5sum, ls etc. instead.
> 
> I think people should be comparing on the basis of the version numbers
> of Debian packages rather than the dates of the files they contain.

Yes.  However, knowing when a package was built isn't the same as
knowing the version number.  I don't intend to change dpkg so that it
doesn't extract the file modification times.

What the man program should do is examine the inode-modification time
as well as or instead of the file-modification time.  This is quite
robust, but will cause gratuitous reformatting if the
inode-modification times are reset (for example, after a restore from
backup - Linux doesn't have a production-capable `dump/restore' yet).

Alternatively it could set the file-modification time on the cache
file to that of the source file.  This only works if there is only
one source file, but it does allow cached copies to be preserved
across reinstallation of the same version of a package.

> However, there is a problem with this scheme; it means that the man
> pages will get rebuilt even if they haven't actually changed between
> different package versions.  (They may anyway, but it should be
> avoidable ATM.)

In general there doesn't seem to be a way of resolving that, without
checksumming the manpage file.

> >What to do about stray catman pages left behind? They should be
> >deleted. dpkg knows when things are deinstall so this is probably the
> >best tool to remove then. Maybe a script to grep/sed/awk the .list
> >file to generate possibe catman name to delete. Maybe the scripts used
> >to delete old catman pages could also check for straycats and delete
> >them. (but not under the local hierachy?)

I disagree, I don't think dpkg should do anything special about
manpages.

> How about having a weekly (or maybe even monthly) cron job which
> checks that all the catpages have corresponding man pages still on the
> system and removes any that don't?

That sounds like a good idea.  The job could run when man rebuilds the
manpage indices, or finds that a cached page that it thought was OK
wasn't.

Ian.