Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 15/11/16 02:42 PM, Michał Górny wrote:
> On Tue, 15 Nov 2016 13:57:14 -0500
> Ian Stakenvicius <axs@g.o> 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...