Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1929

Summary:	RFE: more intelligent makewhatis.cron
Product:	[Retired] Red Hat Linux	Reporter:	Chris Siebenmann <cks-rhbugzilla>
Component:	man	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	5.2
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-04-09 23:29:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Siebenmann 1999-04-01 08:18:37 UTC

Right now, the whatis indexes are only rebuild weekly,
presumably because it's a heavy-duty procedure; this can
be a long wait in some circumstances.

 It would be nice if makewhatis.cron (or makewhatis
itself) was more intelligent, and only rebuilt the
whatis indexes if they were out of date. Then it would
be sensible to run makewhatis.cron more often, such as
every night.

Comment 1 David Lawrence 1999-04-01 21:46:59 UTC

Thank you for your suggestion. This has been passed on to a developer.

Comment 2 Michael K. Johnson 1999-04-09 22:22:59 UTC

Seems like a weekly script to rebuild the database and a daily
script to update the database would be about right...

Comment 3 Michael K. Johnson 1999-04-09 23:29:59 UTC

Fixed in man-1.5g-2.  makewhatis already had a -u option for
doing fast updates to the database.  There's now a weekly
script that recreates the database and a daily script that
updates it very quickly.  makewhatis itself already had all
the needed intelligence -- we just needed to harness it.
We wouldn't want to avoid rebuilding the database once a week
because the updates aren't sorted, just appended, and over
time an actively-maintained system would end up with a rather
messed-up database providing essentially random apropos output...

Thanks for the suggestion!