On 15/11/16 12:56 PM, William Hubbs wrote:
> On Tue, Nov 15, 2016 at 05:56:27PM +0100, Michał Górny wrote:
>> On Tue, 15 Nov 2016 09:49:22 -0600
>> "Dustin C. Hatch" <admiralnemo@gmail.com> wrote:
>>
>>> On 2016-11-14 23:09, Michał Górny wrote:
>>>> On Mon, 14 Nov 2016 18:23:10 -0600
>>>> William Hubbs <williamh@gentoo.org> wrote:
>>>>   
>>>>> Hi all,
>>>>>
>>>>> I have been working on splitting the tmpfiles functionality out of
>>>>> OpenRC [1], and I believe the new package is about to enter the tree.
>>>>>
>>>>> OpenRC itself doesn't need this package to boot since it doesn't use
>>>>> tmpfiles.d files, but other software does need it.
>>>>>
>>>>> This brings up a couple of questions.
>>>>>
>>>>> Since we now will have two different ways to process tmpfiles, is
>>>>> virtual/tmpfiles appropriate, with the default being opentmpfiles?  
>>>>
>>>> Yes. Virtual will allow us to control list of supported implementations
>>>> easily. We can also use it to control different versions of tmpfiles
>>>> format.
>>>>   
>>>>> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles
>>>>> be added to @system, or should we have the packages that need it rdepend
>>>>> on it directly? I tend to lean toward the second option.  
>>>>
>>>> We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft
>>>> somewhere. In case that draft uses DEPEND, it just occurred to me that
>>>> we need RDEPEND for pkg_postinst().
>>>>   
>>>
>>> What about administrator-specified temporary files in /etc/tmpfiles.d?
>>> It would be rather unfortunate to have stuff suddenly stop working
>>> because an OpenRC got updated and stopped creating these temporary files.
>>
>> I'd say it would be reasonable for OpenRC to pull it in, since OpenRC
>> used to provide tmpfiles support for some time already.
> 
> 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.
> 
> William
> 

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.

If end-users are deploying their own tmpfiles.d specifics despite
nothing else needing it, then yes there will be a potential conflict
there, but I think a news item on openrc should suffice for this.

This does however bring up a good question -- I assume that this new
package installs the tmpfiles.dev and tmpfiles.setup init scripts
correct?  Does that mean systemd will be adjusted to also install
these files, or are we going to have yet another package
(tmpfiles-init-scripts or some such) that will install them?  If we're
leaving the init scripts in openrc then openrc *should* RDEPEND on the
virtual.