1 |
On Tue, Nov 15, 2016 at 12:09 AM, Michał Górny <mgorny@g.o> wrote: |
2 |
> On Mon, 14 Nov 2016 18:23:10 -0600 |
3 |
> William Hubbs <williamh@g.o> wrote: |
4 |
> |
5 |
>> Hi all, |
6 |
>> |
7 |
>> I have been working on splitting the tmpfiles functionality out of |
8 |
>> OpenRC [1], and I believe the new package is about to enter the tree. |
9 |
>> |
10 |
>> OpenRC itself doesn't need this package to boot since it doesn't use |
11 |
>> tmpfiles.d files, but other software does need it. |
12 |
>> |
13 |
>> This brings up a couple of questions. |
14 |
>> |
15 |
>> Since we now will have two different ways to process tmpfiles, is |
16 |
>> virtual/tmpfiles appropriate, with the default being opentmpfiles? |
17 |
> |
18 |
> Yes. Virtual will allow us to control list of supported implementations |
19 |
> easily. We can also use it to control different versions of tmpfiles |
20 |
> format. |
21 |
> |
22 |
>> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles |
23 |
>> be added to @system, or should we have the packages that need it rdepend |
24 |
>> on it directly? I tend to lean toward the second option. |
25 |
> |
26 |
> We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft |
27 |
> somewhere. |
28 |
|
29 |
Said draft is on github. It is a work-in-progress that I have not |
30 |
touched for a few months. |
31 |
|
32 |
https://github.com/floppym/gentoo/blob/tmpfiles-eclass/eclass/tmpfiles.eclass |