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
red /root # time makewhatis
zcat: ./in.telnetd.8.gz: No such file or directory
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
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
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
bash-2.05a# time makewhatis
zcat: ./in.telnetd.8.gz: No such file or directory
I forgot to add, you can also specify certain paths to rebuild:
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...