Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] tmpfiles virtual
Date: Tue, 15 Nov 2016 16:51:04
Message-Id: CAGfcS_mdeh2s90OGeFtuiZqFkS91=-O9E8esuX8j6ZjV3iotcw@mail.gmail.com
In Reply to: Re: [gentoo-dev] tmpfiles virtual by "Dustin C. Hatch"
1 On Tue, Nov 15, 2016 at 10:49 AM, Dustin C. Hatch <admiralnemo@×××××.com> wrote:
2 > On 2016-11-14 23:09, Michał Górny wrote:
3 >> On Mon, 14 Nov 2016 18:23:10 -0600
4 >> William Hubbs <williamh@g.o> wrote:
5 >>
6 >>> Hi all,
7 >>>
8 >>> I have been working on splitting the tmpfiles functionality out of
9 >>> OpenRC [1], and I believe the new package is about to enter the tree.
10 >>>
11 >>> OpenRC itself doesn't need this package to boot since it doesn't use
12 >>> tmpfiles.d files, but other software does need it.
13 >>>
14 >>> This brings up a couple of questions.
15 >>>
16 >>> Since we now will have two different ways to process tmpfiles, is
17 >>> virtual/tmpfiles appropriate, with the default being opentmpfiles?
18 >>
19 >> Yes. Virtual will allow us to control list of supported implementations
20 >> easily. We can also use it to control different versions of tmpfiles
21 >> format.
22 >>
23 >>> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles
24 >>> be added to @system, or should we have the packages that need it rdepend
25 >>> on it directly? I tend to lean toward the second option.
26 >>
27 >> We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft
28 >> somewhere. In case that draft uses DEPEND, it just occurred to me that
29 >> we need RDEPEND for pkg_postinst().
30 >>
31 >
32 > What about administrator-specified temporary files in /etc/tmpfiles.d?
33 > It would be rather unfortunate to have stuff suddenly stop working
34 > because an OpenRC got updated and stopped creating these temporary files.
35 >
36
37 Does it create them today? I thought this was a new feature addition.
38 If it does then news should cover that situation, and the admin can
39 just add either the virtual or the preferred implementation to their
40 @world.
41
42 --
43 Rich