[gentoo-dev] tmpfiles virtual

[gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

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?

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.

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=599044

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

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().

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Dustin C. Hatch]

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.

-- 
♫Dustin

Re: [gentoo-dev] tmpfiles virtual

[Rich Freeman]

On Tue, Nov 15, 2016 at 10:49 AM, 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.
>

Does it create them today?  I thought this was a new feature addition.
If it does then news should cover that situation, and the admin can
just add either the virtual or the preferred implementation to their
@world.

-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Mike Gilbert]

On Tue, Nov 15, 2016 at 12:09 AM, Michał Górny <mgorny@gentoo.org> 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.

Said draft is on github. It is a work-in-progress that I have not
touched for a few months.

https://github.com/floppym/gentoo/blob/tmpfiles-eclass/eclass/tmpfiles.eclass

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

On Tue, Nov 15, 2016 at 12:11:52PM -0500, Mike Gilbert wrote:
> On Tue, Nov 15, 2016 at 12:09 AM, Michał Górny <mgorny@gentoo.org> 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.
> 
> Said draft is on github. It is a work-in-progress that I have not
> touched for a few months.
> 
> https://github.com/floppym/gentoo/blob/tmpfiles-eclass/eclass/tmpfiles.eclass

I like a lot of it, but I'll bring it to the list with a couple of
changes.

Thanks,

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 3325 bytes --]

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.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

On Tue, 15 Nov 2016 12:22:42 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Nov 15, 2016 at 12:11:52PM -0500, Mike Gilbert wrote:
> > On Tue, Nov 15, 2016 at 12:09 AM, Michał Górny <mgorny@gentoo.org> 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.
> > 
> > Said draft is on github. It is a work-in-progress that I have not
> > touched for a few months.
> > 
> > https://github.com/floppym/gentoo/blob/tmpfiles-eclass/eclass/tmpfiles.eclass
> 
> I like a lot of it, but I'll bring it to the list with a couple of
> changes.

Please send me your changes for early review since I was planning to do
a few changes as well ;-).

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

On Tue, 15 Nov 2016 13:57:14 -0500
Ian Stakenvicius <axs@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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1905 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Mike Gilbert]

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

Right; if the functionality is being stripped out of OpenRC, it will
definitely need to remain installed and provide init.d scripts for
processing at boot time.

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 2929 bytes --]

On 15/11/16 02:56 PM, Mike Gilbert wrote:
> On Tue, Nov 15, 2016 at 2:51 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>> On 15/11/16 02:42 PM, Michał Górny wrote:
>>> On Tue, 15 Nov 2016 13:57:14 -0500
>>> Ian Stakenvicius <axs@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...
> 
> Right; if the functionality is being stripped out of OpenRC, it will
> definitely need to remain installed and provide init.d scripts for
> processing at boot time.
> 

Right, so we're back to how will we deal with the init scripts for
openrc?  I agree that the virtual suffices, and that openrc doesn't
need tmpfiles.d processing and so likely shouldn't depend on the
virtual.  But the init scripts need to be there in some form or another.

Can we make the virtual install the init.d scripts?  I know it's not a
true virtual in that case but still..

Or will opentmpfiles install the current set of scripts while systemd
will install a systemd-specific set of scripts for openrc to use?
That could work, and likely makes sense as the calling commands and
possibly arguments will differ...




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2930 bytes --]

On Wed, Nov 16, 2016 at 08:57:57AM -0500, Ian Stakenvicius wrote:
> On 15/11/16 02:56 PM, Mike Gilbert wrote:
> > On Tue, Nov 15, 2016 at 2:51 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> >> On 15/11/16 02:42 PM, Michał Górny wrote:
> >>> On Tue, 15 Nov 2016 13:57:14 -0500
> >>> Ian Stakenvicius <axs@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...
> > 
> > Right; if the functionality is being stripped out of OpenRC, it will
> > definitely need to remain installed and provide init.d scripts for
> > processing at boot time.
> > 
> 
> Right, so we're back to how will we deal with the init scripts for
> openrc?  I agree that the virtual suffices, and that openrc doesn't
> need tmpfiles.d processing and so likely shouldn't depend on the
> virtual.  But the init scripts need to be there in some form or another.

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 3145 bytes --]

On 16/11/16 10:08 AM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 08:57:57AM -0500, Ian Stakenvicius wrote:
>> On 15/11/16 02:56 PM, Mike Gilbert wrote:
>>> On Tue, Nov 15, 2016 at 2:51 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>>>> On 15/11/16 02:42 PM, Michał Górny wrote:
>>>>> On Tue, 15 Nov 2016 13:57:14 -0500
>>>>> Ian Stakenvicius <axs@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...
>>>
>>> Right; if the functionality is being stripped out of OpenRC, it will
>>> definitely need to remain installed and provide init.d scripts for
>>> processing at boot time.
>>>
>>
>> Right, so we're back to how will we deal with the init scripts for
>> openrc?  I agree that the virtual suffices, and that openrc doesn't
>> need tmpfiles.d processing and so likely shouldn't depend on the
>> virtual.  But the init scripts need to be there in some form or another.
> 
> 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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 2506 bytes --]

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.

GIVEN THIS, if a system has both systemd and openrc installed (that
is, they dual-boot), then virtual/tmpfiles will NOT bring in
opentmpfiles, and so if opentmpfiles is the only package that installs
init scripts then openrc won't trigger any processing of
/usr/lib/tmpfiles.d/* at bootup in this situation.

Just because systemd is installed doesn't mean it's the actual init in
use.  We deal with this with virtual/udev via udev-init-scripts, and
we will need -some sort- of similar situation here.  This case needs
to be addressed, and be done WITHOUT requiring the end-user to add
opentmpfiles to @world by hand.

I think, given the opentmpfiles and the systemd tmpfiles commands and
arguments can differ, it would likely make more sense to have a
virtual service in openrc (that is, keep tmpfiles.dev and
tmpfiles.setup as virtuals) and have opentmpfiles and systemd both
install init scripts for their respective implementation that will
provide each of those in openrc.  The alternative would be to make a
tmpfiles-init-scripts package that will contain a single set of
scripts that'll call either the opentmpfiles or the systemd-tmpfiles
implementation at runtime depending on what is available.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]

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.

> GIVEN THIS, if a system has both systemd and openrc installed (that
> is, they dual-boot), then virtual/tmpfiles will NOT bring in
> opentmpfiles, and so if opentmpfiles is the only package that installs
> init scripts then openrc won't trigger any processing of
> /usr/lib/tmpfiles.d/* at bootup in this situation.
 
 The way this is handled on the systemd side right now is with a PDEPEND
 on udev-init-scripts, which forces them to be installed even on a pure
 systemd system. That is a separate issue, which I may open as a bug
 against systemd, but discussing it goes on a separate thread probably.

If we follow that, I would add opentmpfiles to the pdepend.

> I think, given the opentmpfiles and the systemd tmpfiles commands and
> arguments can differ, it would likely make more sense to have a
> virtual service in openrc (that is, keep tmpfiles.dev and
> tmpfiles.setup as virtuals) and have opentmpfiles and systemd both
> install init scripts for their respective implementation that will
> provide each of those in openrc.

This is a separate issue. The service scripts will provide virtuals, but
openrc itself doesn't reference them. The only service I know about that
references them is kmod-static-nodes; it runs before tmpfiles.dev, which
is in the sysinit runlevel. tmpfiles.setup is in the boot runlevel so it
runs early enough that there haven't been issues.

> The alternative would be to make a
> tmpfiles-init-scripts package that will contain a single set of
> scripts that'll call either the opentmpfiles or the systemd-tmpfiles
> implementation at runtime depending on what is available.

I can make the service scripts call the systemd-tmpfiles service if it
is available or if not call the opentmpfiles implementation.

I'm not sure whether it is worth having a separate package for the
service scripts in this case.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 557 bytes --]

On 16/11/16 03:21 PM, William Hubbs wrote:
> 
> I can make the service scripts call the systemd-tmpfiles service if it
> is available or if not call the opentmpfiles implementation.
> 
> I'm not sure whether it is worth having a separate package for the
> service scripts in this case.

That would depend on where the service scripts are sitting, I guess --
do you mean here that openrc will keep its current tmpfiles.dev and
tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
RDEPEND or PDEPEND on virtual/tmpfiles ?






[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
> On 16/11/16 03:21 PM, William Hubbs wrote:
> > 
> > I can make the service scripts call the systemd-tmpfiles service if it
> > is available or if not call the opentmpfiles implementation.
> > 
> > I'm not sure whether it is worth having a separate package for the
> > service scripts in this case.
> 
> That would depend on where the service scripts are sitting, I guess --
> do you mean here that openrc will keep its current tmpfiles.dev and
> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
> RDEPEND or PDEPEND on virtual/tmpfiles ?

No, those scripts will be removed from OpenRC. If you grep through
OpenRC, you will see that once they are removed, they are never actually
referred to by any other services that are part of OpenRC.

The scripts will be put in opentmpfiles and that ebuild will install
them.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1146 bytes --]

On 16/11/16 06:16 PM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>> On 16/11/16 03:21 PM, William Hubbs wrote:
>>>
>>> I can make the service scripts call the systemd-tmpfiles service if it
>>> is available or if not call the opentmpfiles implementation.
>>>
>>> I'm not sure whether it is worth having a separate package for the
>>> service scripts in this case.
>>
>> That would depend on where the service scripts are sitting, I guess --
>> do you mean here that openrc will keep its current tmpfiles.dev and
>> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>> RDEPEND or PDEPEND on virtual/tmpfiles ?
> 
> No, those scripts will be removed from OpenRC. If you grep through
> OpenRC, you will see that once they are removed, they are never actually
> referred to by any other services that are part of OpenRC.
> 
> The scripts will be put in opentmpfiles and that ebuild will install
> them.
> 
> William
> 

Then we're back to the exact same issue.  opentmpfiles won't be
installed if systemd is installed, so the scripts won't get installed.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
> On 16/11/16 06:16 PM, William Hubbs wrote:
> > On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
> >> On 16/11/16 03:21 PM, William Hubbs wrote:
> >>>
> >>> I can make the service scripts call the systemd-tmpfiles service if it
> >>> is available or if not call the opentmpfiles implementation.
> >>>
> >>> I'm not sure whether it is worth having a separate package for the
> >>> service scripts in this case.
> >>
> >> That would depend on where the service scripts are sitting, I guess --
> >> do you mean here that openrc will keep its current tmpfiles.dev and
> >> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
> >> RDEPEND or PDEPEND on virtual/tmpfiles ?
> > 
> > No, those scripts will be removed from OpenRC. If you grep through
> > OpenRC, you will see that once they are removed, they are never actually
> > referred to by any other services that are part of OpenRC.
> > 
> > The scripts will be put in opentmpfiles and that ebuild will install
> > them.
> > 
> > William
> > 
> 
> Then we're back to the exact same issue.  opentmpfiles won't be
> installed if systemd is installed, so the scripts won't get installed.
 
 Why not? we can just add opentmpfiles to the pdepend of systemd the
 same way udev-init-scripts is.

 William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 1637 bytes --]

On 16/11/16 06:25 PM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>> On 16/11/16 06:16 PM, William Hubbs wrote:
>>> On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>>>> On 16/11/16 03:21 PM, William Hubbs wrote:
>>>>>
>>>>> I can make the service scripts call the systemd-tmpfiles service if it
>>>>> is available or if not call the opentmpfiles implementation.
>>>>>
>>>>> I'm not sure whether it is worth having a separate package for the
>>>>> service scripts in this case.
>>>>
>>>> That would depend on where the service scripts are sitting, I guess --
>>>> do you mean here that openrc will keep its current tmpfiles.dev and
>>>> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>>>> RDEPEND or PDEPEND on virtual/tmpfiles ?
>>>
>>> No, those scripts will be removed from OpenRC. If you grep through
>>> OpenRC, you will see that once they are removed, they are never actually
>>> referred to by any other services that are part of OpenRC.
>>>
>>> The scripts will be put in opentmpfiles and that ebuild will install
>>> them.
>>>
>>> William
>>>
>>
>> Then we're back to the exact same issue.  opentmpfiles won't be
>> installed if systemd is installed, so the scripts won't get installed.
>  
>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>  same way udev-init-scripts is.
> 
>  William
> 

Wait, so you're going to require systemd have a PDEPEND on
opentmpfiles, so that OpenRC doesn't need to have one, when it's
openrc that needs the script files that opentmpfiles installs??



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Mike Gilbert]

On Wed, Nov 16, 2016 at 6:25 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>> On 16/11/16 06:16 PM, William Hubbs wrote:
>> > On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>> >> On 16/11/16 03:21 PM, William Hubbs wrote:
>> >>>
>> >>> I can make the service scripts call the systemd-tmpfiles service if it
>> >>> is available or if not call the opentmpfiles implementation.
>> >>>
>> >>> I'm not sure whether it is worth having a separate package for the
>> >>> service scripts in this case.
>> >>
>> >> That would depend on where the service scripts are sitting, I guess --
>> >> do you mean here that openrc will keep its current tmpfiles.dev and
>> >> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>> >> RDEPEND or PDEPEND on virtual/tmpfiles ?
>> >
>> > No, those scripts will be removed from OpenRC. If you grep through
>> > OpenRC, you will see that once they are removed, they are never actually
>> > referred to by any other services that are part of OpenRC.
>> >
>> > The scripts will be put in opentmpfiles and that ebuild will install
>> > them.
>> >
>> > William
>> >
>>
>> Then we're back to the exact same issue.  opentmpfiles won't be
>> installed if systemd is installed, so the scripts won't get installed.
>
>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>  same way udev-init-scripts is.

Sorry, but that really does not make any sense.

Re: [gentoo-dev] tmpfiles virtual

[Rich Freeman]

On Wed, Nov 16, 2016 at 6:45 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> On 16/11/16 06:25 PM, William Hubbs wrote:
>> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>>> On 16/11/16 06:16 PM, William Hubbs wrote:
>>>> On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>>>>> On 16/11/16 03:21 PM, William Hubbs wrote:
>>>>>>
>>>>>> I can make the service scripts call the systemd-tmpfiles service if it
>>>>>> is available or if not call the opentmpfiles implementation.
>>>>>>
>>>>>> I'm not sure whether it is worth having a separate package for the
>>>>>> service scripts in this case.
>>>>>
>>>>> That would depend on where the service scripts are sitting, I guess --
>>>>> do you mean here that openrc will keep its current tmpfiles.dev and
>>>>> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>>>>> RDEPEND or PDEPEND on virtual/tmpfiles ?
>>>>
>>>> No, those scripts will be removed from OpenRC. If you grep through
>>>> OpenRC, you will see that once they are removed, they are never actually
>>>> referred to by any other services that are part of OpenRC.
>>>>
>>>> The scripts will be put in opentmpfiles and that ebuild will install
>>>> them.
>>>>
>>>> William
>>>>
>>>
>>> Then we're back to the exact same issue.  opentmpfiles won't be
>>> installed if systemd is installed, so the scripts won't get installed.
>>
>>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>>  same way udev-init-scripts is.
>
> Wait, so you're going to require systemd have a PDEPEND on
> opentmpfiles, so that OpenRC doesn't need to have one, when it's
> openrc that needs the script files that opentmpfiles installs??
>

I agree, this doesn't make sense.

If systemd-tmpfiles can work when systemd isn't running I could see an
argument for having systemd install init.d scripts to run it (it seems
strange, but it wouldn't be so strange if it weren't bundled).  Of
course you still run into a collision with opentmpfiles if both are
installed at once, unless they use different script, or the init.d
scripts can run either and are installed in a split package.

But, it definitely doesn't make sense to have systemd depend on opentmpfiles.

But, if systemd-tmpfiles can run without systemd I don't get why
everybody is in such a rush to basically re-implement it.  That isn't
really a problem though, if somebody wants to code another <whatever>
that isn't a problem.

-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[Mike Gilbert]

On Wed, Nov 16, 2016 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Nov 16, 2016 at 6:45 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>> On 16/11/16 06:25 PM, William Hubbs wrote:
>>> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>>>> On 16/11/16 06:16 PM, William Hubbs wrote:
>>>>> On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>>>>>> On 16/11/16 03:21 PM, William Hubbs wrote:
>>>>>>>
>>>>>>> I can make the service scripts call the systemd-tmpfiles service if it
>>>>>>> is available or if not call the opentmpfiles implementation.
>>>>>>>
>>>>>>> I'm not sure whether it is worth having a separate package for the
>>>>>>> service scripts in this case.
>>>>>>
>>>>>> That would depend on where the service scripts are sitting, I guess --
>>>>>> do you mean here that openrc will keep its current tmpfiles.dev and
>>>>>> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>>>>>> RDEPEND or PDEPEND on virtual/tmpfiles ?
>>>>>
>>>>> No, those scripts will be removed from OpenRC. If you grep through
>>>>> OpenRC, you will see that once they are removed, they are never actually
>>>>> referred to by any other services that are part of OpenRC.
>>>>>
>>>>> The scripts will be put in opentmpfiles and that ebuild will install
>>>>> them.
>>>>>
>>>>> William
>>>>>
>>>>
>>>> Then we're back to the exact same issue.  opentmpfiles won't be
>>>> installed if systemd is installed, so the scripts won't get installed.
>>>
>>>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>>>  same way udev-init-scripts is.
>>
>> Wait, so you're going to require systemd have a PDEPEND on
>> opentmpfiles, so that OpenRC doesn't need to have one, when it's
>> openrc that needs the script files that opentmpfiles installs??
>>
>
> I agree, this doesn't make sense.
>
> If systemd-tmpfiles can work when systemd isn't running I could see an
> argument for having systemd install init.d scripts to run it (it seems
> strange, but it wouldn't be so strange if it weren't bundled).  Of
> course you still run into a collision with opentmpfiles if both are
> installed at once, unless they use different script, or the init.d
> scripts can run either and are installed in a split package.

Either of these options seem reasonable to me.

It's possible (though unlikely) that someone would install systemd
simply for unadulterated udev and tmpfiles support. I'm happy to
install init scripts to support that.

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 2181 bytes --]

On 16/11/16 09:19 PM, Mike Gilbert wrote:
> On Wed, Nov 16, 2016 at 8:41 PM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Wed, Nov 16, 2016 at 6:45 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>>> On 16/11/16 06:25 PM, William Hubbs wrote:
>>>> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>>>>> > [...]
>>>>> Then we're back to the exact same issue.  opentmpfiles won't be
>>>>> installed if systemd is installed, so the scripts won't get installed.
>>>>
>>>>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>>>>  same way udev-init-scripts is.
>>>
>>> Wait, so you're going to require systemd have a PDEPEND on
>>> opentmpfiles, so that OpenRC doesn't need to have one, when it's
>>> openrc that needs the script files that opentmpfiles installs??
>>>
>>
>> I agree, this doesn't make sense.
>>
>> If systemd-tmpfiles can work when systemd isn't running I could see an
>> argument for having systemd install init.d scripts to run it (it seems
>> strange, but it wouldn't be so strange if it weren't bundled).  Of
>> course you still run into a collision with opentmpfiles if both are
>> installed at once, unless they use different script, or the init.d
>> scripts can run either and are installed in a split package.
> 
> Either of these options seem reasonable to me.
> 
> It's possible (though unlikely) that someone would install systemd
> simply for unadulterated udev and tmpfiles support. I'm happy to
> install init scripts to support that.
> 

Unfortunately, I think the best means of handling this would still be
an init-scripts package the same as we do for udev, that both systemd
and opentmpfiles would depend on -- the sole reason being, that this
package could easily the appropriate scripts to the boot and sysinit
runlevels when installed, and that may prove difficult to sort out via
openrc virtual services.

tmpfiles.setup is easy enough to do via 'need' or 'want' in depend
sections, but tmpfiles.dev has to have a 'before dev', which means
sysinit, and I'm not sure if a service in 'default' can trigger
something to be started in sysinit via a 'need' or 'want' dep.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

On Wed, 16 Nov 2016 14:21:41 -0600
William Hubbs <williamh@gentoo.org> 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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 2073 bytes --]

On 17/11/16 01:03 AM, Michał Górny wrote:
> On Wed, 16 Nov 2016 14:21:41 -0600
> William Hubbs <williamh@gentoo.org> 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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Thu, Nov 17, 2016 at 10:02:25AM -0500, Ian Stakenvicius wrote:
> On 17/11/16 01:03 AM, Michał Górny wrote:
> > On Wed, 16 Nov 2016 14:21:41 -0600
> > William Hubbs <williamh@gentoo.org> 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.

Doesn't that bring into question the need of RDEPEND in the
eclass itself since it doesn't have a pkg_postinst function? I could
remove the rdepend from the eclass and add the following to the
documentation of the tmpfiles_process function:

# Warning: Be sure that you rdepend on virtual/tmpfiles if you use this
# function in your ebuild.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

On Thu, 17 Nov 2016 10:02:25 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 17/11/16 01:03 AM, Michał Górny wrote:
> > On Wed, 16 Nov 2016 14:21:41 -0600
> > William Hubbs <williamh@gentoo.org> 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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]

On Thu, 17 Nov 2016 19:46:41 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> On Thu, 17 Nov 2016 10:02:25 -0500
> Ian Stakenvicius <axs@gentoo.org> wrote:
> 
> > On 17/11/16 01:03 AM, Michał Górny wrote:  
> > > On Wed, 16 Nov 2016 14:21:41 -0600
> > > William Hubbs <williamh@gentoo.org> 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.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 3318 bytes --]

On 17/11/16 12:22 PM, William Hubbs wrote:
> On Thu, Nov 17, 2016 at 10:02:25AM -0500, Ian Stakenvicius wrote:
>> On 17/11/16 01:03 AM, Michał Górny wrote:
>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>> William Hubbs <williamh@gentoo.org> 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.
> 
> Doesn't that bring into question the need of RDEPEND in the
> eclass itself since it doesn't have a pkg_postinst function? I could
> remove the rdepend from the eclass and add the following to the
> documentation of the tmpfiles_process function:
> 
> # Warning: Be sure that you rdepend on virtual/tmpfiles if you use this
> # function in your ebuild.
> 
> William
> 

No I don't think so.  The eclass uses these tmpfiles.d-processing
commands in order to do its work, so therefore it needs to make sure
the tools are there.  As mgorny said earlier this RIGHT NOW means
putting it in RDEPEND, but in a Future-EAPI it won't be RDEPEND but
instead some other *DEPEND.

Likewise, I don't think it's pertinent to inherit the eclass in order
to ensure system runtime support of tmpfiles.d processing -- there's
nothing to say that the eclass won't disappear in a year or two after
all (because, say, the tmpfiles.d daemon starts using inotify and
instantly processes any newly installed files, hypothetically)




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]

On Thu, Nov 17, 2016 at 07:49:07PM +0100, Michał Górny wrote:
> On Thu, 17 Nov 2016 19:46:41 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Thu, 17 Nov 2016 10:02:25 -0500
> > Ian Stakenvicius <axs@gentoo.org> wrote:
> > 
> > > On 17/11/16 01:03 AM, Michał Górny wrote:  
> > > > On Wed, 16 Nov 2016 14:21:41 -0600
> > > > William Hubbs <williamh@gentoo.org> 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.
 
 I disagree. We mount a couple of things, /proc, /sys and /run off the
 top of my head, but that doesn't justify adding tmpfiles as an rdepend
 of OpenRC.

 William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 4482 bytes --]

On 17/11/16 01:49 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 19:46:41 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
> 
>> On Thu, 17 Nov 2016 10:02:25 -0500
>> Ian Stakenvicius <axs@gentoo.org> wrote:
>>
>>> On 17/11/16 01:03 AM, Michał Górny wrote:  
>>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>>> William Hubbs <williamh@gentoo.org> 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)





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5472 bytes --]

On Thu, 17 Nov 2016 14:10:28 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 17/11/16 01:49 PM, Michał Górny wrote:
> > On Thu, 17 Nov 2016 19:46:41 +0100
> > Michał Górny <mgorny@gentoo.org> wrote:
> >   
> >> On Thu, 17 Nov 2016 10:02:25 -0500
> >> Ian Stakenvicius <axs@gentoo.org> wrote:
> >>  
> >>> On 17/11/16 01:03 AM, Michał Górny wrote:    
> >>>> On Wed, 16 Nov 2016 14:21:41 -0600
> >>>> William Hubbs <williamh@gentoo.org> 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.

The package does not depend on functionality provided by tmpfiles.d.
The package does depend on directory being created. Which was normally
done via keepdir.

However, then William changed /var/run to a symlink to /run. Now all
packages that relied on keepdir need tmpfiles.d or some other magic to
recreate the directories.

The whole point of the eclass is to provide a reasonable way to combine
both without having to do the same thing twice. That is, create
the directory in postinst and install a tmpfiles.d entry to make it
possible to recreate it on boot.

If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d
implementation more than to run postinst. After postinst, the directory
is created and the user is happy. However, if he uses OpenRC, then
OpenRC will make sure the directory disappears on next boot.

So why should ebuild add dependencies to solve a limitation caused by
OpenRC?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 7731 bytes --]

On 17/11/16 02:42 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 14:10:28 -0500
> Ian Stakenvicius <axs@gentoo.org> wrote:
> 
>> On 17/11/16 01:49 PM, Michał Górny wrote:
>>> On Thu, 17 Nov 2016 19:46:41 +0100
>>> Michał Górny <mgorny@gentoo.org> wrote:
>>>   
>>>> On Thu, 17 Nov 2016 10:02:25 -0500
>>>> Ian Stakenvicius <axs@gentoo.org> wrote:
>>>>  
>>>>> On 17/11/16 01:03 AM, Michał Górny wrote:    
>>>>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>>>>> William Hubbs <williamh@gentoo.org> 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.
> 
> The package does not depend on functionality provided by tmpfiles.d.
> The package does depend on directory being created. Which was normally
> done via keepdir.
> 

Last I checked, tmpfiles.d *.conf filed did a whole lot more than just
ensure missing directories are created.  Has the functionality been
stripped down to just that, now?


> However, then William changed /var/run to a symlink to /run. Now all
> packages that relied on keepdir need tmpfiles.d or some other magic to
> recreate the directories.

OpenRC's init scripts all do that already, more or less.  tmpfiles.d
*.conf files are not used for this purpose -- definitely not by
OpenRC, and most likely also not by upstream packages.


> The whole point of the eclass is to provide a reasonable way to combine
> both without having to do the same thing twice. That is, create
> the directory in postinst and install a tmpfiles.d entry to make it
> possible to recreate it on boot.

I thought the reason for the eclass was so that when a package is
installed, you don't need to reboot or otherwise trigger manually your
system's tmpfiles.d processing to have it do the first-run process
with the new *.conf file?


> If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d
> implementation more than to run postinst. 

Sure he does.  eix needs it to ensure files exist in /var/cache/ , for
instance.  dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists
and has the correct permissions.  Neither of those has got anything to
do with openrc's needs at boot time.  Whether it's openrc or a fork of
upstart or some strange busybox-only script or whatever init/rc system
that's used, opentmpfiles provides the capability of processing these
tmpfiles.d *.conf files and can be triggered at boot time to do it (or
via cron, or with it being started as a daemon maybe later I presume)


> After postinst, the directory
> is created and the user is happy. However, if he uses OpenRC, then
> OpenRC will make sure the directory disappears on next boot.
> 
> So why should ebuild add dependencies to solve a limitation caused by
> OpenRC?

This would be because opentmpfiles is its own project now rather than
something shipped as part of (or even needed by) openrc.  And so, it's
now a runtime dep *when and only when* not processing the tmpfiles.d
*.conf file is going to make the package fail at runtime, internally
and intrinsically to the package itself (not to its init script or any
other init/rc related thing).

Realistically, software should ensure the directories it needs at
runtime are created through their own code, but upstreams are lazy and
so they don't bother because, hey, we can have this tmpfiles.d *.conf
file to have the system do it for us!  In those cases, we'd need that
rdepend.

-----

Part of what you brought up here did trigger a bit of a concern for me
though, and that is, we want to be careful that we as developers and
package maintainers don't start using this eclass and tmpfiles.d
*.conf files -instead of- keepdir.  I'm hoping that this was never the
intention, but in case it was I wanted to check.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Rich Freeman]

On Thu, Nov 17, 2016 at 3:07 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> Realistically, software should ensure the directories it needs at
> runtime are created through their own code, but upstreams are lazy and
> so they don't bother because, hey, we can have this tmpfiles.d *.conf
> file to have the system do it for us!

This isn't really being lazy.  This is just not re-inventing the
wheel.  If there is a standard way to ensure that directories are set
up correctly (especially if they're volatile, or you have a
first-time-every-time scenario like a container) then why not use it?

It certainly makes more sense than a bunch of shell code in a unit
file (which then must be duplicated in an init.d script), or having
the program run as root, create directories, and then drop privs.

It was less of an issue when things were less volatile.  However the
trend in servers especially has been towards volatility.  Every boot
basically is the first boot.  A lot more stuff ends up on a tmpfs as
well.

> In those cases, we'd need that rdepend.

I tend to agree with this thinking.  If the package needs these
directories at runtime, and the tmpfiles.d config is the mechanism to
create it, then the package has a runtime dependency on a program that
will do what it says.

That said, I'm not 100% on this as this is a bit of an unusual
situation.  This is generally boot-time configuration so you have a
package run-time dependency on a package being there at boot time.  It
isn't exactly the typical sort of requirement.


-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5111 bytes --]

On Thu, 17 Nov 2016 15:07:32 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 17/11/16 02:42 PM, Michał Górny wrote:
> > The package does not depend on functionality provided by tmpfiles.d.
> > The package does depend on directory being created. Which was normally
> > done via keepdir.
> >   
> 
> Last I checked, tmpfiles.d *.conf filed did a whole lot more than just
> ensure missing directories are created.  Has the functionality been
> stripped down to just that, now?

The basic and most common functionality is creating files/dirs,
and ensuring permissions. The additional functionality includes writing
data to existing files (like procfs) and cleanups. However, the latter
can only be safely done at boot, so we're more focused on the former.

> > However, then William changed /var/run to a symlink to /run. Now all
> > packages that relied on keepdir need tmpfiles.d or some other magic to
> > recreate the directories.  
> 
> OpenRC's init scripts all do that already, more or less.  tmpfiles.d
> *.conf files are not used for this purpose -- definitely not by
> OpenRC, and most likely also not by upstream packages.

So do you expect all eix users to have to run an init script for eix to
be able to use it?

> > The whole point of the eclass is to provide a reasonable way to combine
> > both without having to do the same thing twice. That is, create
> > the directory in postinst and install a tmpfiles.d entry to make it
> > possible to recreate it on boot.  
> 
> I thought the reason for the eclass was so that when a package is
> installed, you don't need to reboot or otherwise trigger manually your
> system's tmpfiles.d processing to have it do the first-run process
> with the new *.conf file?

Yes. That is, to have the temporary directories/files created and/or
permissions set without having to reboot your system. Or to do that
manually in the ebuild, when you're already installing a well-defined
file that explains how to do that.

> > If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d
> > implementation more than to run postinst.   
> 
> Sure he does.  eix needs it to ensure files exist in /var/cache/ , for
> instance.  dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists
> and has the correct permissions.  Neither of those has got anything to
> do with openrc's needs at boot time.  Whether it's openrc or a fork of
> upstart or some strange busybox-only script or whatever init/rc system
> that's used, opentmpfiles provides the capability of processing these
> tmpfiles.d *.conf files and can be triggered at boot time to do it (or
> via cron, or with it being started as a daemon maybe later I presume)

You're missing the point. A purely minimal OpenRC-free system with no
volatile filesystems doesn't require any specific action at boot. It's
perfectly happy with the directories created by ebuild. Why would you
require the user of that system to install a tool he won't be using
anyway?

> > After postinst, the directory
> > is created and the user is happy. However, if he uses OpenRC, then
> > OpenRC will make sure the directory disappears on next boot.
> > 
> > So why should ebuild add dependencies to solve a limitation caused by
> > OpenRC?  
> 
> This would be because opentmpfiles is its own project now rather than
> something shipped as part of (or even needed by) openrc.  And so, it's
> now a runtime dep *when and only when* not processing the tmpfiles.d
> *.conf file is going to make the package fail at runtime, internally
> and intrinsically to the package itself (not to its init script or any
> other init/rc related thing).

Are you going to expect all packages with init scripts to depend
on OpenRC now, because your common-assumed use case requires the init
script to do something? Should we also make them depend on systemd at
the same time for completeness? And possibly on bash, vim, etc. so that
all those extra files get really used.

> Realistically, software should ensure the directories it needs at
> runtime are created through their own code, but upstreams are lazy and
> so they don't bother because, hey, we can have this tmpfiles.d *.conf
> file to have the system do it for us!  In those cases, we'd need that
> rdepend.

So now I'm disallowed to run eix-update as a regular user because it
should be able to create its own directory that normally the packaging
should ensure?

> -----
> 
> Part of what you brought up here did trigger a bit of a concern for me
> though, and that is, we want to be careful that we as developers and
> package maintainers don't start using this eclass and tmpfiles.d
> *.conf files -instead of- keepdir.  I'm hoping that this was never the
> intention, but in case it was I wanted to check.

It is the intention whenever the directory is volatile. In other words,
whenever Portage already spits a big QA warning that your keepdir is
not going to survive a reboot and/or cache cleanup.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 931 bytes --]

[gentoo-dev] Re: tmpfiles virtual

[Martin Vaeth]

Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Nov 17, 2016 at 3:07 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
>>
>> Realistically, software should ensure the directories it needs at
>> runtime are created through their own code, but upstreams are lazy [...]
>
> This isn't really being lazy.  This is just not re-inventing the
> wheel.

++
Conceptionally, it is also a question of efficiency and clean code
separation: Why should several independent scripts of e.g. eix first
care about directories (and force being run with root permissions...).
More important, the latter is also a security topic:

> or having
> the program run as root, create directories, and then drop privs.

eix had such code originally, but this required running quite a lot
of code with root permissions, while now running everything with
dropped permissions is possible.

One could have written an init-script only to create the
directories, but instead of providing such support for each
init system separately, it is perhaps better to use the more
standard "tmpfiles.d"

>> In those cases, we'd need that rdepend.
>
> I tend to agree with this thinking.

++
But the argument of Ian is correct: If the user has both
systemd and openrc installed (and thus virtual/tmpfiles.d
is satisfied) he would not understand why tmpfiles.d is
not processed if he starts the system with openrc.

[gentoo-dev] Re: tmpfiles virtual

[Martin Vaeth]

Rich Freeman <rich0@gentoo.org> wrote:
>
> If systemd-tmpfiles can work when systemd isn't running

According to a brief test (not very exhaustive), this seems to work,
though I did not investigate whether it requires that e.g. dbus is
running.

Without entering the discussion _how_ an init-script should be
installed, I would welcome if that script would autodetect
which variant is installed and if it could be configured which
variant is chosen if both are installed:

For instance, the systemd-tmpfiles implementation has some
features concerning btrfs which are not (yet) supported by
opentmpfiles. Some users might want to use that features.
On the other hand, some users might prefer to be able to boot
properly even if systemd/systemd-tmpfiles blows up for them
for some reason...

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

[-- Attachment #1.1: Type: text/plain, Size: 6182 bytes --]

On 17/11/16 03:50 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 15:07:32 -0500
> Ian Stakenvicius <axs@gentoo.org> wrote:
>>
>> OpenRC's init scripts all do that already, more or less.  tmpfiles.d
>> *.conf files are not used for this purpose -- definitely not by
>> OpenRC, and most likely also not by upstream packages.
> 
> So do you expect all eix users to have to run an init script for eix to
> be able to use it?
> 

They already do -- said init script is called tmpfiles.setup and as
you already know it's a requirement due to /var/cache/eix needing to
be portage:portage and exist despite there not being a guarantee of
/var/cache being preserved.


>>> The whole point of the eclass is to provide a reasonable way to combine
>>> both without having to do the same thing twice. That is, create
>>> the directory in postinst and install a tmpfiles.d entry to make it
>>> possible to recreate it on boot.  
>>
>> I thought the reason for the eclass was so that when a package is
>> installed, you don't need to reboot or otherwise trigger manually your
>> system's tmpfiles.d processing to have it do the first-run process
>> with the new *.conf file?
> 
> Yes. That is, to have the temporary directories/files created and/or
> permissions set without having to reboot your system. Or to do that
> manually in the ebuild, when you're already installing a well-defined
> file that explains how to do that.

Right -- I presume that said file is usually being provided by
upstream, rather than the package maintainer, though?  Because there
should be very few instances so far as I know that gentoo dev's would
need to create tmpfiles.d *.conf files as part of their packaging efforts.


>>> If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d
>>> implementation more than to run postinst.   
>>
>> Sure he does.  eix needs it to ensure files exist in /var/cache/ , for
>> instance.  dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists
>> and has the correct permissions.  Neither of those has got anything to
>> do with openrc's needs at boot time.  Whether it's openrc or a fork of
>> upstart or some strange busybox-only script or whatever init/rc system
>> that's used, opentmpfiles provides the capability of processing these
>> tmpfiles.d *.conf files and can be triggered at boot time to do it (or
>> via cron, or with it being started as a daemon maybe later I presume)
> 
> You're missing the point. A purely minimal OpenRC-free system with no
> volatile filesystems doesn't require any specific action at boot. It's
> perfectly happy with the directories created by ebuild. Why would you
> require the user of that system to install a tool he won't be using
> anyway?

When you say 'volatile filesystems' I assume then you're ignoring FHS
paths where there are no persistence guarantees?  Just because there's
no tmpfs doesn't mean there's no volatility..


> 
>>> After postinst, the directory
>>> is created and the user is happy. However, if he uses OpenRC, then
>>> OpenRC will make sure the directory disappears on next boot.
>>>
>>> So why should ebuild add dependencies to solve a limitation caused by
>>> OpenRC?  
>>
>> This would be because opentmpfiles is its own project now rather than
>> something shipped as part of (or even needed by) openrc.  And so, it's
>> now a runtime dep *when and only when* not processing the tmpfiles.d
>> *.conf file is going to make the package fail at runtime, internally
>> and intrinsically to the package itself (not to its init script or any
>> other init/rc related thing).
> 
> Are you going to expect all packages with init scripts to depend
> on OpenRC now, because your common-assumed use case requires the init
> script to do something? Should we also make them depend on systemd at
> the same time for completeness? And possibly on bash, vim, etc. so that
> all those extra files get really used.
> 

No.  That would be unnecessary as there is, afaik, the requirement of
SOME sort of init or rc system in @system already right?

The thing is, in THIS case, OpenRC upstream is washing their hands of
it.  Which means, its up to the new package that actually -does- the
processing to install an init script that calls itself (which makes
sense) if openrc is booted.  All fine and dandy except:

#1, we should have something other than the end-user's @world to make
sure this is installed (hence RDEPEND on it in packages that need it
to be run) because openrc isn't apparently going to depend on it,

#2 we need to somehow reconcile the fact that if systemd is installed
despite openrc being booted, there still won't be any init scripts
because the virtual won't bring in opentmpfiles.

And #3, we need a clean way to make openrc actually start the init
scripts when they're present and not start them when they're not,
since openrc itself isn't carrying them.

Now as i said before, i _am_ in agreement with you that all of this
would be easier to just have integrated in openrc -- if openrc (the
ebuild, not the upstream) RDEPENDs on the virtual and installs
tmpfiles.dev and tmpfiles.setup init scripts that call either
opentmpfiles or systemd-tmpfilesd, that would sweep all three of the
above points under the rug and everything would work better than now.
People using something other an init/rc system other than openrc and
systemd aren't really supported anyways, so we can just leave it at that.


>> -----
>>
>> Part of what you brought up here did trigger a bit of a concern for me
>> though, and that is, we want to be careful that we as developers and
>> package maintainers don't start using this eclass and tmpfiles.d
>> *.conf files -instead of- keepdir.  I'm hoping that this was never the
>> intention, but in case it was I wanted to check.
> 
> It is the intention whenever the directory is volatile. In other words,
> whenever Portage already spits a big QA warning that your keepdir is
> not going to survive a reboot and/or cache cleanup.

*nod* that makes sense.  I assume most of these files are coming from
upstream though right?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Re: tmpfiles virtual

[Rich Freeman]

On Thu, Nov 17, 2016 at 4:58 PM, Martin Vaeth <martin@mvath.de> wrote:
>
> For instance, the systemd-tmpfiles implementation has some
> features concerning btrfs which are not (yet) supported by
> opentmpfiles. Some users might want to use that features.
>

Well, this was the main reason I suggested that we could just use
systemd-tmpfiles.  It is essentially everybody's reference
implementation already.  But, if somebody wants to re-implement it
that is their right, and certainly the virtual is the way to go about
it.

-- 
Rich

Re: [gentoo-dev] tmpfiles virtual

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

I have picked this message to reply to so I'm at the end of the thread.

The plan is to create a separate package for the init scripts,
tmpfiles-init-scripts. This package will also add the init scripts to
the appropriate runlevels.

The providers of virtual/tmpfiles are opentmpfiles or systemd.

The only question left is how to handle the dependencies.

I'm thinking that the providers of virtual/tmpfiles should pdepend on
sys-apps/tmpfiles-init-scripts?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [gentoo-dev] tmpfiles virtual

[Mike Gilbert]

On Fri, Nov 18, 2016 at 1:42 PM, William Hubbs <williamh@gentoo.org> wrote:
> I have picked this message to reply to so I'm at the end of the thread.
>
> The plan is to create a separate package for the init scripts,
> tmpfiles-init-scripts. This package will also add the init scripts to
> the appropriate runlevels.
>
> The providers of virtual/tmpfiles are opentmpfiles or systemd.
>
> The only question left is how to handle the dependencies.
>
> I'm thinking that the providers of virtual/tmpfiles should pdepend on
> sys-apps/tmpfiles-init-scripts?

There's no need for PDEPEND -- there is no circular dependency to break there.

Providers of virtual/tmpfiles should RDEPEND on it.