slocate will not function until this is run, which may
create initial confusion for users immediately after
Matt, maybe we should run it as part of the post installation
Install time would be bad (it would get some files and not others
if it was started in the middle of the install, and it could mess
up disk space calculations); even spawning it at boot could be
bad because it could conflict with the cron version starting,
which means it needs to use a lock file if we choose to do this.
I'd rather see a more general approach to the problem. locate
complained as well.
This should be done as part of a larger schdeule of tasks that would
be run at the first boot into the new installed system.
This would require some re-engineering work for now, so I guess people
will have to live with locate not working on the first day.
Is this problem still around? If so, I would guess that slocate.cron could be
added to firstboot now.
Yes, this problem is still around, but (aside from RHEL 3) it's
ameliorated by anacron; the delay is now a little over an hour, not up
to a whole day as before. (Perhaps anacron was also around when this
bug was first filed, but I really don't know one way or the other.)
Especially with the existence of anacron, trying to fix this may not
be worth the bother. As it is, users already need to be aware that
locate is using a snapshot that could be up to a day old; in
comparison, not having locate work for the first hour (or so) after
installation is a very minor issue IMO.
This is already fixed, so closing as "NOT A BUG" anymore.