On Thu, 2019-04-25 at 16:07 -0400, Michael Orlitzky wrote: > 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. >
Wrong. tmpfiles_process() requires virtual/tmpfiles on any system, including daemontools, bare minimal init and whatever. Keeping it installed afterwards is a minor side effect, and technical limitation of our dependency types (lack of install-depend). -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
