(Per request in bug #662438) The nightly cron job that we have now creates a directory, changes ownership/permissions of it, and then uses "su" to drop privileges before generating the cache: cachedir="/var/cache/man" if [ ! -d "${cachedir}" ]; then mkdir -p "${cachedir}" chown man:man "${cachedir}" chmod 0755 "${cachedir}" fi exec su man -s /bin/sh -c 'nice mandb --quiet' 2>/dev/null If the /var/cache/man directory is guaranteed to exist (and have the correct permissions), then the "drop privileges" part of the cron job can be simplified by launching the job as the "man" user directly, e.g. with <minute> <hour> * * * man mandb --quiet in a file under /etc/cron.d. However, Lars' last comment on bug #662438 suggests that setting up /var/cache/man in the ebuild's src_install() may be undesirable: > No can do as this would put the content of /var/cache/man into the package's > content which we wanna avoid (by doing it in pkg_preinst). Without that, you can still cram all of those mkdir/chown/chmod commands onto one line, but it will be a lot uglier. (Why is it bad to have the package manager own /var/cache/man/.keepdir?)
The man-db package already installs a tmpfiles snippet. > $ cat /usr/lib/tmpfiles.d/man-db.conf > d /var/cache/man 0755 man man 1w The man-db ebuild should be updated to call tmpfiles_process from tmpfiles.eclass in pkg_postinst.
> (Why is it bad to have the package manager own /var/cache/man/.keepdir?) That would trigger this QA check. https://gitweb.gentoo.org/proj/portage.git/tree/bin/install-qa-check.d/20runtime-directories
(In reply to Mike Gilbert from comment #2) > > (Why is it bad to have the package manager own /var/cache/man/.keepdir?) > > That would trigger this QA check. Since /var/cache is persistent, I would object, at least as far as ".keep" files are concerned. The directory /var/cache/man is specifically mentioned in the FHS: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05.html Nevertheless, doing so now goes beyond the effort I'm willing to invest. Note also that OpenRC now processes tmpfiles.d entries at boot, so that directory should already exist unless you try really hard to shoot yourself in the foot. On the other hand (regardless of the tmpfiles entry), since /var/cache is persistent, it should already exist from the ebuild unless you try really hard to shoot yourself in the foot.
(In reply to Michael Orlitzky from comment #3) > /var/cache is persistent Citation needed. The linked FHS section does not use the word "persistent". In fact, it says that files under /var/cache can be manually deleted and applications must be able to regenerate the data. The sysadmin is free to delete any .keep file installed by the package manager.
(In reply to Mike Gilbert from comment #4) > (In reply to Michael Orlitzky from comment #3) > > /var/cache is persistent > > Citation needed. > Same page, "The data must remain valid between invocations of the application and rebooting the system."
(In reply to Mike Gilbert from comment #4) > The sysadmin is free to delete any .keep file installed by the package manager. I do see the issue here, but in theory the .keep file can be regenerated too. It won't hurt the system if someone deletes it; and the spec doesn't say that you're allowed to delete directories. Ultimately the .keep file is just an implementation detail, and there's a point at which we're just making our lives difficult by not doing the obvious thing.
What's the point of creating the directory in src_install, if we have to re-create it on every reboot anyway? There's no benefit, so I don't see why you are arguing about this.
(In reply to Mike Gilbert from comment #7) > What's the point of creating the directory in src_install, if we have to > re-create it on every reboot anyway? There's no benefit, so I don't see why > you are arguing about this. I've pointed out why I think the QA warning is wrong in this case, and why /var/cache/man should stick around with whatever permissions/ownership we give it in src_install. Doing it once correctly would save us from duplicating it in pkg_preinst, at every reboot, and in every cron run. It would also simplify the cron job, and allow said cron job to drop privileges without the non-portable "su" call. I'm not going to argue for it any further. I don't think the cron job can be simplified so long as we still pointlessly try to recreate, re-chown, and re-chmod /var/cache/man every time the job runs. It's not that big of a deal. My feelings won't be hurt if this gets WONTFIX'd.
It turns out, /etc/cron.d is not even standard. Support is patched in on debian/redhat and in some modern cron implementations, but it isn't part of e.g. vixie-cron, even though vixie-cron's ebuild runs "keepdir /etc/cron.d" for some unimaginable reason.
