This warning is emitted by portage with a QA prefix, even though it isn't an official policy, so I'm asking QA to reconsider it:
QA Notice: This ebuild installs into paths that should be created at
runtime. To fix, simply do not install into these directories. Instead,
your package should create dirs on the fly at runtime as needed via init
What this comes down to is a "simple" question: can top-level directories be purged from /var/cache? (And if so, when?)
There are essentially two answers to this question. One of them ("no") is sound in theory and practice and is simple to implement, while the other ("yes, at any time") is none of those things.
The filesystem hierarchy standard says that "files may be expired..." from /var/cache, but says nothing about directories. Yes, on Linux a directory is implemented as a file -- but I believe this implementation detail is beyond the scope of the FHS. Thus I believe we are within our FHS rights to take the simple approach, and create permanent subdirectories of /var/cache.
The choice becomes important when you consider that many applications that might make use of /var/cache run as an unprivileged user, and that /var/cache itself is writable only by the superuser. If the "foo" daemon runs as the "foo" user, and if it wants to utilize /var/cache, the natural thing to do is to create /var/cache/foo as root, and give ownership of it to the "foo" user.
But as a package maintainer, when do I do that? If the "foo" package creates the directory, then it gets created once, when the package is installed. If /var/cache/foo may then be deleted, we have a problem. The alternative is to treat /var/cache like we do /run, and to require the service manager (systemd, OpenRC, etc.) to create the directory at some point with the correct ownership. This is also problematic if the directory can be deleted -- it only gets recreated when the machine is rebooted. This somewhat violates the wording of the specification, because while the application can regenerate that data, it can't regenerate it in the right place; so every application needs to be able to fall back to a second location if /var/cache/<pkg> is inaccessible. It also involves the service manager in something it would otherwise play no part in.
Thus my common sense tells me that persistent, top-level subdirectories in /var/cache are the simple and reliable answer. Nothing on a Gentoo system deletes those subdirectories, and this approach is already familiar to Gentoo developers who use things like /var/lib/<pkg>.
In contrast, the current policy encourages developers to *avoid* the easy and reliable solution in favor of something like a tmpfiles.d entry that is more fragile, more complicated, and platform-specific. It's doing more harm than good.
This bug report paraphrases a recent post to the fhs-discuss mailing list,
where I've only received one response so far, from the BSD side of things. It supports the simple approach.
Please consider reverting that QA warning, and encouraging developers to keepdir things under /var/cache with fixed permissions.
Ping. This just came up again with sys-apps/mandb. Right now it's relying on a tmpfiles entry to re-create /var/cache/man at boot time with the correct permissions, because it installs a cron job that drops permissions and needs to be able to write there.
The only way this works on a non-systemd system is through the unconscionably-insecure opentmpfiles, which will never be fixed, for multiple reasons that I won't get into to avoid being reported to comrel. It would simplify things greatly, improve security, and make me happy to be able to say "keepdir /var/cache/man" once in the ebuild and be done with it. I think doing so is allowed by the FHS and is generally the smart approach (see my OP).