atm the man page database is updated via a cronjob. this does a lot of unnecessary work when the install man pages havent changed, or just changed a little. if we had a hook that executed the update for the specific man pages that changed, then we'd do exactly as much work as was needed and not any more. we already do something like this for info pages and its directory ...
I suppose it will go through the paths listed in $MANPATH and if a timestamp has changed then it will call `makewhatis -u <path>`. That seems easy enough.
When thinking about implementing this, I realized that man pages occupy a much larger number of directories than info files (especially if there are localized manpages). I suppose that we can still use the same approach though. It's just that we'll have to save and compare mtimes for a much larger number of directories.
portage has the exact list of man pages that were added/removed/updated ... i think passing that info along to the hook should be sufficient ?
Yeah, can use the CONTENTS to keep track of which directories got modified. Should the makewhatis be called after each package is installed, so that the whatis database is always kept in sync during a series of upgrades, or should we do it in one big batch at the end (for a small increase in efficiency)? I think it's best to call it after each package, so the whatis database is always in sync.
either should work i think
@pms-bugs: I don't see anything in PMS about the way that portage calls install-info. Do we want it there? There are other similar things like man pages and icon caches (bug 420277) to think about.
(In reply to comment #6) > @pms-bugs: I don't see anything in PMS about the way that portage calls > install-info. Do we want it there? There are other similar things like man > pages and icon caches (bug 420277) to think about. How about postmerge.d or something like that where various packages (and users) could install relevant hooks?
(In reply to comment #7) > How about postmerge.d or something like that where various packages (and > users) could install relevant hooks? Sure. Maybe it would also be useful to have a config file format that allows file path patterns to be mapped to hooks. So, the package manager would only have to call a specific hook when a matched file is installed or removed.
this also applies for 1. icon cache 2. desktop mime database 3. shared mime info database 4. fontcache and probably other things as well that can and should be handled on PM side example: I just uninstalled 100 packages and almost every single one of them called on or two of those eclass functions, essentially slowing down the procedure and causing unnecessary ebuild/eclass code PM can check for changes in the relevant directories and call these functions accordingly. Most of them don't seem complicated and don't indicate that they need to be called in a very special way/with arguments.
I mean: PM could call those functions after all 100 packages have been (un)installed...
I would propose using triggers to select the postmerge.d hooks to run: * In the post_install phase the ebuild/eclass touches /var/tmp/portage/postmerge/hook-name * Portage runs after finishing all installations: for f in /var/tmp/portage/postmerge/* ; do /etc/portage/postmerge.d/$(basename $f) ; done
(In reply to comment #9) i'm not sure your examples are all appropriate. are those all caches that, if not updated, would cause misbehavior in programs ? we can get away with delaying ldconfig because even if the cache didn't exist or was incomplete, the runtime would cope with it.
Expanding on the icon cache use-case: Whenever a package installs icons a sub-directory of /usr/share/icons/hicolor, ideally it should touch the hicolor directory. This will trigger a re-cache by KDE, for example.
