Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 61 - makewhatis doesn't get run at all.
Summary: makewhatis doesn't get run at all.
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Thilo Bangert (RETIRED) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-01-06 22:33 UTC by Daniel Robbins (RETIRED)
Modified: 2011-10-30 22:21 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Robbins (RETIRED) gentoo-dev 2002-01-06 22:33:15 UTC
solution: make emerge run it just like it dynamically regenerates the info pages.
Comment 1 Grant Goodyear (RETIRED) gentoo-dev 2002-01-07 12:06:49 UTC
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

Comment 2 Geert Bevin 2002-01-08 16:47:50 UTC
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
Comment 3 Daniel Robbins (RETIRED) gentoo-dev 2002-01-14 00:06:39 UTC
yes, we can run it as a cron job, I suppose.
Comment 4 Daniel Robbins (RETIRED) gentoo-dev 2002-01-30 10:54:07 UTC
yep, we need it in a cron job.
Comment 5 Leo Lipelis (RETIRED) gentoo-dev 2002-02-12 23:59:44 UTC
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.
Comment 6 Leo Lipelis (RETIRED) gentoo-dev 2002-02-13 00:36:57 UTC
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).
Comment 7 Martin Schlemmer (RETIRED) gentoo-dev 2002-02-13 01:10:30 UTC
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.
Comment 8 Leo Lipelis (RETIRED) gentoo-dev 2002-02-13 10:45:45 UTC
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.
Comment 9 Donny Davies (RETIRED) gentoo-dev 2002-02-13 12:19:21 UTC
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.
Comment 10 Daniel Robbins (RETIRED) gentoo-dev 2002-02-13 12:21:33 UTC
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! :)
Comment 11 Scott Moynes 2002-02-26 22:52:03 UTC
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
Comment 12 Scott Moynes 2002-02-26 22:56:28 UTC
I forgot to add, you can also specify certain paths to rebuild:

makewhatis /usr/X11R6/man
Comment 13 Martin Schlemmer (RETIRED) gentoo-dev 2002-02-27 17:16:38 UTC
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 :)  )
Comment 14 Daniel Robbins (RETIRED) gentoo-dev 2002-03-12 12:54:01 UTC
The solution to this is to replace dcron with vixie cron.  Let's do it.
Comment 15 Thilo Bangert (RETIRED) (RETIRED) gentoo-dev 2002-04-24 12:20:10 UTC
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...