1 |
On 17/11/16 03:50 PM, Michał Górny wrote: |
2 |
> On Thu, 17 Nov 2016 15:07:32 -0500 |
3 |
> Ian Stakenvicius <axs@g.o> wrote: |
4 |
>> |
5 |
>> OpenRC's init scripts all do that already, more or less. tmpfiles.d |
6 |
>> *.conf files are not used for this purpose -- definitely not by |
7 |
>> OpenRC, and most likely also not by upstream packages. |
8 |
> |
9 |
> So do you expect all eix users to have to run an init script for eix to |
10 |
> be able to use it? |
11 |
> |
12 |
|
13 |
They already do -- said init script is called tmpfiles.setup and as |
14 |
you already know it's a requirement due to /var/cache/eix needing to |
15 |
be portage:portage and exist despite there not being a guarantee of |
16 |
/var/cache being preserved. |
17 |
|
18 |
|
19 |
>>> The whole point of the eclass is to provide a reasonable way to combine |
20 |
>>> both without having to do the same thing twice. That is, create |
21 |
>>> the directory in postinst and install a tmpfiles.d entry to make it |
22 |
>>> possible to recreate it on boot. |
23 |
>> |
24 |
>> I thought the reason for the eclass was so that when a package is |
25 |
>> installed, you don't need to reboot or otherwise trigger manually your |
26 |
>> system's tmpfiles.d processing to have it do the first-run process |
27 |
>> with the new *.conf file? |
28 |
> |
29 |
> Yes. That is, to have the temporary directories/files created and/or |
30 |
> permissions set without having to reboot your system. Or to do that |
31 |
> manually in the ebuild, when you're already installing a well-defined |
32 |
> file that explains how to do that. |
33 |
|
34 |
Right -- I presume that said file is usually being provided by |
35 |
upstream, rather than the package maintainer, though? Because there |
36 |
should be very few instances so far as I know that gentoo dev's would |
37 |
need to create tmpfiles.d *.conf files as part of their packaging efforts. |
38 |
|
39 |
|
40 |
>>> If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d |
41 |
>>> implementation more than to run postinst. |
42 |
>> |
43 |
>> Sure he does. eix needs it to ensure files exist in /var/cache/ , for |
44 |
>> instance. dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists |
45 |
>> and has the correct permissions. Neither of those has got anything to |
46 |
>> do with openrc's needs at boot time. Whether it's openrc or a fork of |
47 |
>> upstart or some strange busybox-only script or whatever init/rc system |
48 |
>> that's used, opentmpfiles provides the capability of processing these |
49 |
>> tmpfiles.d *.conf files and can be triggered at boot time to do it (or |
50 |
>> via cron, or with it being started as a daemon maybe later I presume) |
51 |
> |
52 |
> You're missing the point. A purely minimal OpenRC-free system with no |
53 |
> volatile filesystems doesn't require any specific action at boot. It's |
54 |
> perfectly happy with the directories created by ebuild. Why would you |
55 |
> require the user of that system to install a tool he won't be using |
56 |
> anyway? |
57 |
|
58 |
When you say 'volatile filesystems' I assume then you're ignoring FHS |
59 |
paths where there are no persistence guarantees? Just because there's |
60 |
no tmpfs doesn't mean there's no volatility.. |
61 |
|
62 |
|
63 |
> |
64 |
>>> After postinst, the directory |
65 |
>>> is created and the user is happy. However, if he uses OpenRC, then |
66 |
>>> OpenRC will make sure the directory disappears on next boot. |
67 |
>>> |
68 |
>>> So why should ebuild add dependencies to solve a limitation caused by |
69 |
>>> OpenRC? |
70 |
>> |
71 |
>> This would be because opentmpfiles is its own project now rather than |
72 |
>> something shipped as part of (or even needed by) openrc. And so, it's |
73 |
>> now a runtime dep *when and only when* not processing the tmpfiles.d |
74 |
>> *.conf file is going to make the package fail at runtime, internally |
75 |
>> and intrinsically to the package itself (not to its init script or any |
76 |
>> other init/rc related thing). |
77 |
> |
78 |
> Are you going to expect all packages with init scripts to depend |
79 |
> on OpenRC now, because your common-assumed use case requires the init |
80 |
> script to do something? Should we also make them depend on systemd at |
81 |
> the same time for completeness? And possibly on bash, vim, etc. so that |
82 |
> all those extra files get really used. |
83 |
> |
84 |
|
85 |
No. That would be unnecessary as there is, afaik, the requirement of |
86 |
SOME sort of init or rc system in @system already right? |
87 |
|
88 |
The thing is, in THIS case, OpenRC upstream is washing their hands of |
89 |
it. Which means, its up to the new package that actually -does- the |
90 |
processing to install an init script that calls itself (which makes |
91 |
sense) if openrc is booted. All fine and dandy except: |
92 |
|
93 |
#1, we should have something other than the end-user's @world to make |
94 |
sure this is installed (hence RDEPEND on it in packages that need it |
95 |
to be run) because openrc isn't apparently going to depend on it, |
96 |
|
97 |
#2 we need to somehow reconcile the fact that if systemd is installed |
98 |
despite openrc being booted, there still won't be any init scripts |
99 |
because the virtual won't bring in opentmpfiles. |
100 |
|
101 |
And #3, we need a clean way to make openrc actually start the init |
102 |
scripts when they're present and not start them when they're not, |
103 |
since openrc itself isn't carrying them. |
104 |
|
105 |
Now as i said before, i _am_ in agreement with you that all of this |
106 |
would be easier to just have integrated in openrc -- if openrc (the |
107 |
ebuild, not the upstream) RDEPENDs on the virtual and installs |
108 |
tmpfiles.dev and tmpfiles.setup init scripts that call either |
109 |
opentmpfiles or systemd-tmpfilesd, that would sweep all three of the |
110 |
above points under the rug and everything would work better than now. |
111 |
People using something other an init/rc system other than openrc and |
112 |
systemd aren't really supported anyways, so we can just leave it at that. |
113 |
|
114 |
|
115 |
>> ----- |
116 |
>> |
117 |
>> Part of what you brought up here did trigger a bit of a concern for me |
118 |
>> though, and that is, we want to be careful that we as developers and |
119 |
>> package maintainers don't start using this eclass and tmpfiles.d |
120 |
>> *.conf files -instead of- keepdir. I'm hoping that this was never the |
121 |
>> intention, but in case it was I wanted to check. |
122 |
> |
123 |
> It is the intention whenever the directory is volatile. In other words, |
124 |
> whenever Portage already spits a big QA warning that your keepdir is |
125 |
> not going to survive a reboot and/or cache cleanup. |
126 |
|
127 |
*nod* that makes sense. I assume most of these files are coming from |
128 |
upstream though right? |