Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 244518 - add a hook for man pages like with info pages
Summary: add a hook for man pages like with info pages
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-26 20:48 UTC by SpanKY
Modified: 2019-09-14 20:01 UTC (History)
5 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 SpanKY gentoo-dev 2008-10-26 20:48:07 UTC
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 ...
Comment 1 Zac Medico gentoo-dev 2008-10-26 22:31:07 UTC
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.
Comment 2 Zac Medico gentoo-dev 2008-11-28 21:43:30 UTC
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.
Comment 3 SpanKY gentoo-dev 2008-11-28 22:06:04 UTC
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 ?
Comment 4 Zac Medico gentoo-dev 2008-11-28 22:25:58 UTC
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.
Comment 5 SpanKY gentoo-dev 2008-11-28 22:40:21 UTC
either should work i think
Comment 6 Zac Medico gentoo-dev 2012-07-05 21:49:53 UTC
@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.
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-07-06 06:44:54 UTC
(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?
Comment 8 Zac Medico gentoo-dev 2012-07-06 21:15:04 UTC
(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.
Comment 9 Julian Ospald 2013-02-13 20:00:21 UTC
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.
Comment 10 Julian Ospald 2013-02-13 20:01:13 UTC
I mean: PM could call those functions after all 100 packages have been (un)installed...
Comment 11 Dennis Schridde 2013-02-13 20:09:47 UTC
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
Comment 12 SpanKY gentoo-dev 2013-02-19 07:29:26 UTC
(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.
Comment 13 Mike Gilbert gentoo-dev 2013-02-25 02:30:31 UTC
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.