| 1 |
On 15/11/16 12:56 PM, William Hubbs wrote: |
| 2 |
> On Tue, Nov 15, 2016 at 05:56:27PM +0100, Michał Górny wrote: |
| 3 |
>> On Tue, 15 Nov 2016 09:49:22 -0600 |
| 4 |
>> "Dustin C. Hatch" <admiralnemo@×××××.com> wrote: |
| 5 |
>> |
| 6 |
>>> On 2016-11-14 23:09, Michał Górny wrote: |
| 7 |
>>>> On Mon, 14 Nov 2016 18:23:10 -0600 |
| 8 |
>>>> William Hubbs <williamh@g.o> wrote: |
| 9 |
>>>> |
| 10 |
>>>>> Hi all, |
| 11 |
>>>>> |
| 12 |
>>>>> I have been working on splitting the tmpfiles functionality out of |
| 13 |
>>>>> OpenRC [1], and I believe the new package is about to enter the tree. |
| 14 |
>>>>> |
| 15 |
>>>>> OpenRC itself doesn't need this package to boot since it doesn't use |
| 16 |
>>>>> tmpfiles.d files, but other software does need it. |
| 17 |
>>>>> |
| 18 |
>>>>> This brings up a couple of questions. |
| 19 |
>>>>> |
| 20 |
>>>>> Since we now will have two different ways to process tmpfiles, is |
| 21 |
>>>>> virtual/tmpfiles appropriate, with the default being opentmpfiles? |
| 22 |
>>>> |
| 23 |
>>>> Yes. Virtual will allow us to control list of supported implementations |
| 24 |
>>>> easily. We can also use it to control different versions of tmpfiles |
| 25 |
>>>> format. |
| 26 |
>>>> |
| 27 |
>>>>> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles |
| 28 |
>>>>> be added to @system, or should we have the packages that need it rdepend |
| 29 |
>>>>> on it directly? I tend to lean toward the second option. |
| 30 |
>>>> |
| 31 |
>>>> We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft |
| 32 |
>>>> somewhere. In case that draft uses DEPEND, it just occurred to me that |
| 33 |
>>>> we need RDEPEND for pkg_postinst(). |
| 34 |
>>>> |
| 35 |
>>> |
| 36 |
>>> What about administrator-specified temporary files in /etc/tmpfiles.d? |
| 37 |
>>> It would be rather unfortunate to have stuff suddenly stop working |
| 38 |
>>> because an OpenRC got updated and stopped creating these temporary files. |
| 39 |
>> |
| 40 |
>> I'd say it would be reasonable for OpenRC to pull it in, since OpenRC |
| 41 |
>> used to provide tmpfiles support for some time already. |
| 42 |
> |
| 43 |
> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to |
| 44 |
> make sure virtual/tmpfiles and opentmpfiles go stable at the same time |
| 45 |
> the new OpenRC does, along with at least one package that uses them. |
| 46 |
> |
| 47 |
> This will also definitely be covered in the upstream OpenRC news. |
| 48 |
> |
| 49 |
> WRT OpenRC pulling it in, it isn't a build or runtime dependency of |
| 50 |
> OpenRC, and it may not even be needed in some cases, so I'm not sure how |
| 51 |
> much sense it makes from the OpenRC level to pull it in or which type of |
| 52 |
> dependency to use for it. |
| 53 |
> |
| 54 |
> William |
| 55 |
> |
| 56 |
|
| 57 |
I'm with William on this. As long as the packages that install items |
| 58 |
(init scripts, whatever) that -do- need tmpfiles.d support depend on |
| 59 |
virtual/tmpfilesd, this will ensure it's installed regardless of |
| 60 |
whether or not openrc depends on the virtual directly. |
| 61 |
|
| 62 |
If end-users are deploying their own tmpfiles.d specifics despite |
| 63 |
nothing else needing it, then yes there will be a potential conflict |
| 64 |
there, but I think a news item on openrc should suffice for this. |
| 65 |
|
| 66 |
This does however bring up a good question -- I assume that this new |
| 67 |
package installs the tmpfiles.dev and tmpfiles.setup init scripts |
| 68 |
correct? Does that mean systemd will be adjusted to also install |
| 69 |
these files, or are we going to have yet another package |
| 70 |
(tmpfiles-init-scripts or some such) that will install them? If we're |
| 71 |
leaving the init scripts in openrc then openrc *should* RDEPEND on the |
| 72 |
virtual. |
Archives