solution: make emerge run it just like it dynamically regenerates the info pages.
Is makewhatis fast enough that running it at every emerge won't be horribly annoying? Immediately after running makewhatis, a second run gave: red /root # time makewhatis zcat: ./in.telnetd.8.gz: No such file or directory real 0m31.864s user 0m21.290s sys 0m9.650s
Personally I find makewhatis too slow to be executed after each emerge. Maybe create an additional package that installs a file which makes it run as a cron task
yes, we can run it as a cron job, I suppose.
yep, we need it in a cron job.
IMHO, it's pretty easy to su to root and type "makewhatis". Also, setting up cron jobs is an administrative task that's really not the same from system to system or from admin to admin. If it's an ebuild that sets up a cron job, what is a good time period? For example, every night at 5 am -- might be bad for laptop users. Every hour -- might be annoying and needless on many systems. All in all, adding a cron entry for whatis would be simpler and take less code and maintenance than it would be writing an ebuild. It would also have the advantage of the end-user/admin knowing precisely the best time to run it. And it's even simpler to simply su to root and just run it as needed, imho.
I just thought about it a bit more. I think a better solution would be, IMHO, if we had portage rebuild whatis at certain times: 1. Right after 'emerge system'. 2. Right after any 'emerge --world update' -- 3. And perhaps every Nth install that adds a man page, where N might be hardcoded to a reasonable value or configurable in /etc/make.globals or such. Rationale for #3: a) many ebuilds do not even add a man page b) if you just happen not to install anything that has man pages, makewhatis doesn't run. c) if you don't emerge new packages often, makewhatis doesn't run often. -- I think #1 and 2 can provide a reasonable (read: better than nothing) default whatis db for all systems. And I don't feel too strongly about #3, because I still think that running makewhatis by hand is best. An easy and generic way might be to have special post-emerge hooks that call a script after each emerge action. That way, a) nothing needs to be hard coded into portage and b) sysadmin can put anything they want there, like makewhatis, or any other script/util they want to run and of course c) give the control to sysadmin. Then #1 and 2 could simply be reasonable defaults for /etc/portage/post-system and /etc/portage/post-world-update that SA could override. (I just invented these /etc locations for argument's sake). And, if you want to get really clever about it, then portage can even pass all kinds of information into these post-emerge action hooks by way of command line arguments. Command line arguments passed to post emerge action scripts/hooks might be something like: pkg name just added, total number of files added, size of files added, how many times main FHS directories were updated (this can be used to tell if a man page was added, because a standard MANPATH dir will get updated then). This mechanism could even be used to provide configurable logging for any portage events that interest SA, with one disadvantage that such logging could not be used to diagnose any problems, because then we would need portage itself to log its actions in detail. With Python exceptions (try/finally) we could make sure that a post event hook runs even if something fails in portage. This kind of logging could be useful regardless of portage's internal logging, because it would be 1) configurable by SA and 2) serve a different purpose (ie, not for troubleshooting, but for system accounting).
This is not really a makewhatis only related problem. We need default cronjobs in Gentoo to work, with /etc/cron.* as well. The only way I know how to do this is, is to use Vixie Cron by default, as it read a systemwide crontab, /etc/crontab. vcron was broken some time ago, but I applied the latest security patches, etc some time ago, and have been using it since without any problem.
Personally, I don't care where cron keeps its crontab file, because I never edit it by hand. I just use 'crontab -l' to list the jobs, and 'crontab -e' to edit the jobs in a safe manner. These commands should be present on any system with cron, and using them is preferred, imho, to hand-editing crontab files. Also, once the user learns how to use crontab command, this skill is transferrable to any *nix system. On the other hand, evidently very few cron implementations keep their root (and why only root? many system-wide cron jobs should not be run as root, for example DB hotbackups, etc.) crontab file in /etc, and if the user learns to hand-edit this file in /etc, they may be stumped if they go somewhere else and try to do this. This bug report is for makewhatis. If there is a separate issue with cron jobs and/or system policy re: crontabs, it should have, imho, its own bug report for better tracking.
in all honesty, i know nothing about makewhatis. to be more honest, i have no desire to fix this - sorry, but i dont. if somebody else is capable, has the time and knowledge to tackle this, please do because im not at all interested. just being honest.
OK, thanks for being honest. You did the right thing, woodchip. This way it doesn't languish in your list 'o bugs when there is someone else who can better handle it. I'm reassigning this to azarah, who now has a working phone! :)
Running makewhatis -u after emerge might be a fix. That flag updates only the new manpages. On my system the time difference is significant: bash-2.05a# time makewhatis -u real 0m2.619s user 0m1.510s sys 0m1.030s bash-2.05a# time makewhatis zcat: ./in.telnetd.8.gz: No such file or directory real 2m20.206s user 0m42.510s sys 0m30.560s
I forgot to add, you can also specify certain paths to rebuild: makewhatis /usr/X11R6/man
After some additional though, here is my take on it: 1) yes, we probibly need some sort of cron system with docs on it. 2) makewhatis is like updatedb. It is something the admin runs, or schedule cron jobs for .. ie not in our domain to setup. Gentoo after all do target developers and admins, no? What do you think. (this is not a way to get out of it, but rather .. do I really want portage/whatever to run jobs whenever it likes ? After all, I am using Gentoo because it *is* the faster distro out there :) )
The solution to this is to replace dcron with vixie cron. Let's do it.
i fixed this by adding a makewhatis.cron that is installed in /etc/cron.daily. makewhatis.cron does not do anything by default - you have to uncomment a line to make it work. i think that would be a good procedure for the updatedb's (fileutils and slocate) too... this will add a cronbase depandancy though, as cronbase installs /etc/cron.daily (+family) i would not want to make them dependant on virtual/cron as you still have to decide wether you want that activated... in other situations a virtual/cron dependancy makes more sense...