On Tue, Apr 03, 2012 at 08:33:41PM +0100, Colin Watson wrote: > On Fri, Mar 30, 2012 at 10:29:05AM -0700, Josh Triplett wrote: > > On Fri, Mar 30, 2012 at 04:59:40PM +0100, Colin Watson wrote: > > (I more frequently tend to find myself using zgrep over the entire > > contents of all manpages, rather than just doing a keyword search over > > a subset of those contents.) > > Nowadays there's 'man -K' too for that, although that doesn't rely on > the database. It should be very significantly faster than zgrep.
Handy, but in general I find man's behavior when multiple manpages match extremely suboptimal. It immediately opens the first matching page, and forces me to walk through each page one-by-one without the ability to backtrack. Grep shows me pagefuls of search results at a time, and I can skim and pick what I need. That doesn't relate to the bug report at hand, though. > > I'd personally prefer to just turn it off entirely, much like the > > locate database. (How crazy would you consider it to split the > > apropos functionality into a separate package, much like locate split > > off of findutils?) > > Well, I think this gets to the heart of the matter: is your root problem > mainly that mandb is slow? If so, I have microbenchmarks that strongly > indicate that the slowness isn't intrinsic, and if I ever manage to put > enough spare hours in a row I intend to fix that. It really shouldn't > need to take more than maybe a few seconds even on not terribly exciting > hardware, and certainly nowhere near as much as locate. See #630799. No, mandb's speed doesn't concern me here. I reported this issue because in general I consider it suboptimal whenever something runs on a periodic basis when it really only needs to run when things change. Very few cron jobs really need to run periodically; most of them represent workarounds for the inability to detect changes and run when those changes occur. Looking at cron.daily, cron.weekly, and cron.monthly on my system, every single cronjob would work better in some other form that didn't blindly run on a periodic basis. > My basic concern here is that splitting packages is forever, or very > nearly, and so I'm reluctant to do so to work around fixable performance > problems. I don't consider this just a performance problem; I'd like to avoid using periodic cronjobs as a substitute for "run when needed". > > However, the need to run mandb for new manpages in /usr/local seems no > > different than the need to run ldconfig for new libraries in /usr/local > > (other than the severity of what happens if you don't). I think you > > could reasonably convey that via NEWS.Debian.gz. > > It's better for software to just work rather than to require > documentation explaining how to make it work, though. I never expect software in /usr/local to Just Work; I have Debian packages when I want things to Just Work. :) /usr/local already represents an area that requires manual maintenance by the administrator: ldconfig, mandb, compiling emacs and Python scripts, running fc-cache for new fonts, running whatever magic thing TeX needs to update its indexes. Cronjobs seem highly suboptimal for these kinds of updates: they run periodically whether they have work to do or not, they delay updates until well after the install has occurred, and they only cover a single package's needs. Perhaps in the future it might make sense to have some standardized mechanism to let packages update on changes to /usr/local. For instance, packages could set file triggers on appropriate parts of /usr/local, and administrators could have an easy way to run all appropriate dpkg triggers after doing a "make install" or equivalent. > > One other thought: what if you made mandb record the stat of the > > directories in the manpath, and then had any tools relying on the mandb > > check that stat and warn if mandb needs to run again? > > That might be workable, I guess, although I worry that it would be > annoying for users without administrative privileges. An increasingly rare class of users. :) But given that fixing it just requires running "mandb", it seems like an extremely simple support issue for an administrator to fix, and add to their checklist of "things to do after 'make install'". > (apropos used to > attempt to raise privileges and update the database automatically; that > was a disaster area and removing it was a big improvement.) Yeah, no good can come of that approach. (That said, in the future when we have some sensible service supervision mechanism, apropos could poke some system daemon and have it fire off a mandb, without attempting to raise its own privileges. Alternatively, mandb could automatically get triggered shortly after any change to directories on the manpath.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
