On 4/24/19 8:53 AM, Michał Górny wrote: > > systemd.eclass has more than one purpose, and therefore such dep didn't > belong there (ebuilds should take care of the dependencies when using > tmpfiles logic from it). tmpfiles.eclass on the other hand has a single > purpose, so we've solved the problem by adding an RDEPEND there. >
I don't quite buy that either: do we assume that users will be running either OpenRC or systemd? If we do, then the RDEPEND on virtual/tmpfiles is redundant. If we don't, then someone running (say) daemontools might want to install a package that comes with a tmpfiles.d entry. Per our small file policy, the tmpfiles.d entry should be installed unconditionally. And if the tmpfiles entry needs to be processed immediately on OpenRC/systemd, then tmpfiles_process() from tmpfiles.eclass must be used to support OpenRC users. But, that will pull in virtual/tmpfiles unnecessarily on a system that's running neither OpenRC nor systemd. This is probably a "go away nobody cares" issue, but I'd prefer to understand it first.
