On Tue, Apr 03, 2012 at 01:54:31PM -0700, Josh Triplett wrote: > On Tue, Apr 03, 2012 at 08:33:41PM +0100, Colin Watson wrote: > > 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,
Add the -w option. > > 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. We may be at an impasse here, because without being convinced that use of local manpaths is truly falling off and that nobody cares about running apropos in them any more (and the bug reports I occasionally get gently suggest otherwise, although man-db gets a low enough volume of bugs that it's hard to ascribe statistical significance to anything), I'm not sure I'm prepared to make a change that I can well believe some users would consider a regression. I guess I could make it configurable somehow, but of course they're conffiles so technically they already are. This seems to be a debate about defaults. > > 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. They're suboptimal, yes; but they're the only stopgap that exists right now. And I don't in general agree that a situation being generally terrible means that small steps to try to make it better aren't worthwhile. > 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. Yes, that would be nice. > > 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'". I'll certainly consider making apropos whine about it. As for the rest, I'm not sure (and it seems fairer to say that straight out rather than just stalling). Some of this is very likely coloured by my experience a couple of jobs back as an unprivileged user on a variety of different Unix systems where they hadn't been correctly configured to build the apropos database and so apropos was useless. We had lots of locally installed software for development - particularly on Solaris which came with terrible userspace software by default - and so it was actually annoying, but they were build systems more than anything else and nobody really wanted to bother about that kind of detail. It was always a point of pride with me that man-db had multiple ways to ensure that it didn't have this problem. (Yes, slightly obsessive, but you'd kind of hope that the man-db maintainer was obsessive about manual pages.) Now, I'm fairly sure that Debian-based systems are less prone to that kind of thing. I certainly hope so. On the other hand, I live in a bubble where this is concerned; I've been working full-time on Ubuntu since 2004, and obviously we're not exactly big on making extensive use of locally installed software for our own purposes, so I like to work on the general assumption that I use a lower percentage of unpackaged software than virtually everyone else. > (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.) If it were a daemon it could use inotify watches; but I definitely don't want to go to the effort of converting it to a daemon. A sufficiently capable service supervision framework could perhaps install inotify watches for it, but I would be concerned about that triggering many times per update; and given that the performance problem with mandb is chiefly "too many forks", that's something I'd prefer to avoid. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
