On 15/11/16 02:42 PM, Michał Górny wrote: > On Tue, 15 Nov 2016 13:57:14 -0500 > Ian Stakenvicius <a...@gentoo.org> wrote: > >> On 15/11/16 12:56 PM, William Hubbs wrote: >>> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to >>> make sure virtual/tmpfiles and opentmpfiles go stable at the same time >>> the new OpenRC does, along with at least one package that uses them. >>> >>> This will also definitely be covered in the upstream OpenRC news. >>> >>> WRT OpenRC pulling it in, it isn't a build or runtime dependency of >>> OpenRC, and it may not even be needed in some cases, so I'm not sure how >>> much sense it makes from the OpenRC level to pull it in or which type of >>> dependency to use for it. >> >> I'm with William on this. As long as the packages that install items >> (init scripts, whatever) that -do- need tmpfiles.d support depend on >> virtual/tmpfilesd, this will ensure it's installed regardless of >> whether or not openrc depends on the virtual directly. > > The ebuilds are going to only need a pkg_*-time dependency on the tool. > While this means RDEPEND at the moment due to our dependency class > limits, we may have a proper dependency type for it in EAPI 7. In this > case, the PM will be allowed to unmerge opentmpfiles as soon > as the package is installed. >
The EBUILDS, yes. This tool isn't just for ebuilds though, it's also for managing tmpfiles.d processing at boot time as well as (i assume) via continuous daemon-like operation for the services that install files into /usr/lib/tmpfiles.d/ (apache, libvirtd, lvm2, mysql, samba are just a few that I have on my own system right now) when systemd isn't installed. Or am I wrong on this? It'd seem odd that we would go through this just to make a tool for ebuilds to use, if non-systemd systems aren't going to use it at boot time as well...
signature.asc
Description: OpenPGP digital signature
