Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 17/11/16 01:49 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 19:46:41 +0100
> Michał Górny <mgorny@g.o> wrote:
>
>> On Thu, 17 Nov 2016 10:02:25 -0500
>> Ian Stakenvicius <axs@g.o> wrote:
>>
>>> On 17/11/16 01:03 AM, Michał Górny wrote:
>>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>>> William Hubbs <williamh@g.o> wrote:
>>>>
>>>>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:
>>>>>> On 16/11/16 12:03 PM, William Hubbs wrote:
>>>>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:
>>>>>>>> On 16/11/16 10:08 AM, William Hubbs wrote:
>>>>>>>>> opentmpfiles will be updated to install the service scripts which
>>>>>>>>> will be run when OpenRC boots a system. There is nothing for
>>>>>>>>> it to do if systemd is used to boot the system.
>>>>>>>>>
>>>>>>>>> William
>>>>>>>>>
>>>>>>>>
>>>>>>>> But there is something to do if openrc is used to boot the system and
>>>>>>>> systemd is the package providing tmpfiles.d processing via the virtual.
>>>>>>>
>>>>>>> The providers (opentmpfiles and systemd) will not block each other, so
>>>>>>> the only way this will happen is if you have openrc and systemd
>>>>>>> installed then forcefully remove opentmpfiles. I think you would not
>>>>>>> want to do that until you are ready to migrate to booting with systemd.
>>>>>>>
>>>>>>> William
>>>>>>>
>>>>>>
>>>>>> I think I'm having a hard time getting across the issue here...:
>>>>>>
>>>>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
>>>>>> or opentmpfiles.
>>>>>>
>>>>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
>>>>>>
>>>>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
>>>>>> need to depend on virtual/tmpfiles in order to make sure that the
>>>>>> system has something installed that will process them at boot-time.
>>>>>
>>>>>  Yes, this will be handled by an RDEPEND in the eclass.
>>>>
>>>> This is a wrong presumption. The eclass needs the virtual only for
>>>> pkg_postinst(). While RDEPEND is how we solve this now, it will no
>>>> longer be necessary in a future EAPI.
>>>>
>>>
>>> This makes sense to me as well -- which means every package that
>>> installs tmpfiles.d/ files should properly RDEPEND on the virtual on
>>> its own when the functionality arisen from those tmpfiles.d files is
>>> non-optional.
>>
>> No, that's now what I meant.
>>
>> The eclass needs the virtual to create temporary directories once,
>> in pkg_postinst(). Period. That's how far it is concerned.
>>
>> If user wants to use a volatile filesystem or any other more complete
>> tmpfiles.d processing, he needs to use a init that supports that. Which
>> means either OpenRC with tmpfiles or systemd. Ebuild has nothing to do
>> with this.
>
> One more thing. I still believe openrc should RDEP on tmpfiles by
> default since openrc is mounting a few standard locations
> (like /var/run) as tmpfs by default.
>

OpenRC isn't using tmpfiles.d *.conf files to do that (although it
could).  I didn't realize tmpfiles.d processing had any direct
relationship or association with tmpfs mounts though (other than it
helps solve the issue of files and dirs disappearing after reboots, of
course).

Part of the point of the virtual (and the reason for the init script
arguments in this thread) is that it makes this functionality not tied
to an init/rc system anymore -- that is:

- systemd will just do it, if its used as init
- systemd if installed can be used to do it from openrc/other-init
- opentmpfiles can be used to do it from openrc/other-init

The part where I see the ebuild coming into play here is for all of
the packages that currently install .conf files into
/usr/lib/tmpfiles.d/ (like apache, libvirt, etc. etc).  If those
packages are doing so explicitly because they non-optionally expect
systemd-tmpfilesd or opentmpfiles to do what's been specified (and
will fail otherwise), then this is an actual RDEPEND for those
packages whether they use the eclass or not.

You are right, though -- we avoid a whole bunch of this if openrc just
RDEPENDs on the virtual and all other packages just assume there is
support for tmpfiles.d processing in whatever init/rc system is used.
However that seems to not be where things are going (at least from
WilliamH's perspective)