slocate will not function until this is run, which may create initial confusion for users immediately after installation.
Matt, maybe we should run it as part of the post installation procedure?
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.