| 1 |
On 16/11/16 10:08 AM, William Hubbs wrote: |
| 2 |
> On Wed, Nov 16, 2016 at 08:57:57AM -0500, Ian Stakenvicius wrote: |
| 3 |
>> On 15/11/16 02:56 PM, Mike Gilbert wrote: |
| 4 |
>>> On Tue, Nov 15, 2016 at 2:51 PM, Ian Stakenvicius <axs@g.o> wrote: |
| 5 |
>>>> On 15/11/16 02:42 PM, Michał Górny wrote: |
| 6 |
>>>>> On Tue, 15 Nov 2016 13:57:14 -0500 |
| 7 |
>>>>> Ian Stakenvicius <axs@g.o> wrote: |
| 8 |
>>>>> |
| 9 |
>>>>>> On 15/11/16 12:56 PM, William Hubbs wrote: |
| 10 |
>>>>>>> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to |
| 11 |
>>>>>>> make sure virtual/tmpfiles and opentmpfiles go stable at the same time |
| 12 |
>>>>>>> the new OpenRC does, along with at least one package that uses them. |
| 13 |
>>>>>>> |
| 14 |
>>>>>>> This will also definitely be covered in the upstream OpenRC news. |
| 15 |
>>>>>>> |
| 16 |
>>>>>>> WRT OpenRC pulling it in, it isn't a build or runtime dependency of |
| 17 |
>>>>>>> OpenRC, and it may not even be needed in some cases, so I'm not sure how |
| 18 |
>>>>>>> much sense it makes from the OpenRC level to pull it in or which type of |
| 19 |
>>>>>>> dependency to use for it. |
| 20 |
>>>>>> |
| 21 |
>>>>>> I'm with William on this. As long as the packages that install items |
| 22 |
>>>>>> (init scripts, whatever) that -do- need tmpfiles.d support depend on |
| 23 |
>>>>>> virtual/tmpfilesd, this will ensure it's installed regardless of |
| 24 |
>>>>>> whether or not openrc depends on the virtual directly. |
| 25 |
>>>>> |
| 26 |
>>>>> The ebuilds are going to only need a pkg_*-time dependency on the tool. |
| 27 |
>>>>> While this means RDEPEND at the moment due to our dependency class |
| 28 |
>>>>> limits, we may have a proper dependency type for it in EAPI 7. In this |
| 29 |
>>>>> case, the PM will be allowed to unmerge opentmpfiles as soon |
| 30 |
>>>>> as the package is installed. |
| 31 |
>>>>> |
| 32 |
>>>> |
| 33 |
>>>> The EBUILDS, yes. |
| 34 |
>>>> |
| 35 |
>>>> This tool isn't just for ebuilds though, it's also for managing |
| 36 |
>>>> tmpfiles.d processing at boot time as well as (i assume) via |
| 37 |
>>>> continuous daemon-like operation for the services that install files |
| 38 |
>>>> into /usr/lib/tmpfiles.d/ (apache, libvirtd, lvm2, mysql, samba are |
| 39 |
>>>> just a few that I have on my own system right now) when systemd isn't |
| 40 |
>>>> installed. |
| 41 |
>>>> |
| 42 |
>>>> Or am I wrong on this? It'd seem odd that we would go through this |
| 43 |
>>>> just to make a tool for ebuilds to use, if non-systemd systems aren't |
| 44 |
>>>> going to use it at boot time as well... |
| 45 |
>>> |
| 46 |
>>> Right; if the functionality is being stripped out of OpenRC, it will |
| 47 |
>>> definitely need to remain installed and provide init.d scripts for |
| 48 |
>>> processing at boot time. |
| 49 |
>>> |
| 50 |
>> |
| 51 |
>> Right, so we're back to how will we deal with the init scripts for |
| 52 |
>> openrc? I agree that the virtual suffices, and that openrc doesn't |
| 53 |
>> need tmpfiles.d processing and so likely shouldn't depend on the |
| 54 |
>> virtual. But the init scripts need to be there in some form or another. |
| 55 |
> |
| 56 |
> opentmpfiles will be updated to install the service scripts which |
| 57 |
> will be run when OpenRC boots a system. There is nothing for |
| 58 |
> it to do if systemd is used to boot the system. |
| 59 |
> |
| 60 |
> William |
| 61 |
> |
| 62 |
|
| 63 |
But there is something to do if openrc is used to boot the system and |
| 64 |
systemd is the package providing tmpfiles.d processing via the virtual. |
Archives