| 1 |
On 16/11/16 12:03 PM, William Hubbs wrote: |
| 2 |
> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote: |
| 3 |
>> On 16/11/16 10:08 AM, William Hubbs wrote: |
| 4 |
>>> opentmpfiles will be updated to install the service scripts which |
| 5 |
>>> will be run when OpenRC boots a system. There is nothing for |
| 6 |
>>> it to do if systemd is used to boot the system. |
| 7 |
>>> |
| 8 |
>>> William |
| 9 |
>>> |
| 10 |
>> |
| 11 |
>> But there is something to do if openrc is used to boot the system and |
| 12 |
>> systemd is the package providing tmpfiles.d processing via the virtual. |
| 13 |
> |
| 14 |
> The providers (opentmpfiles and systemd) will not block each other, so |
| 15 |
> the only way this will happen is if you have openrc and systemd |
| 16 |
> installed then forcefully remove opentmpfiles. I think you would not |
| 17 |
> want to do that until you are ready to migrate to booting with systemd. |
| 18 |
> |
| 19 |
> William |
| 20 |
> |
| 21 |
|
| 22 |
I think I'm having a hard time getting across the issue here...: |
| 23 |
|
| 24 |
1 - we will have a virtual/tmpfiles that will bring in EITHER systemd, |
| 25 |
or opentmpfiles. |
| 26 |
|
| 27 |
2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles) |
| 28 |
|
| 29 |
3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will |
| 30 |
need to depend on virtual/tmpfiles in order to make sure that the |
| 31 |
system has something installed that will process them at boot-time. |
| 32 |
|
| 33 |
GIVEN THIS, if a system has both systemd and openrc installed (that |
| 34 |
is, they dual-boot), then virtual/tmpfiles will NOT bring in |
| 35 |
opentmpfiles, and so if opentmpfiles is the only package that installs |
| 36 |
init scripts then openrc won't trigger any processing of |
| 37 |
/usr/lib/tmpfiles.d/* at bootup in this situation. |
| 38 |
|
| 39 |
Just because systemd is installed doesn't mean it's the actual init in |
| 40 |
use. We deal with this with virtual/udev via udev-init-scripts, and |
| 41 |
we will need -some sort- of similar situation here. This case needs |
| 42 |
to be addressed, and be done WITHOUT requiring the end-user to add |
| 43 |
opentmpfiles to @world by hand. |
| 44 |
|
| 45 |
I think, given the opentmpfiles and the systemd tmpfiles commands and |
| 46 |
arguments can differ, it would likely make more sense to have a |
| 47 |
virtual service in openrc (that is, keep tmpfiles.dev and |
| 48 |
tmpfiles.setup as virtuals) and have opentmpfiles and systemd both |
| 49 |
install init scripts for their respective implementation that will |
| 50 |
provide each of those in openrc. The alternative would be to make a |
| 51 |
tmpfiles-init-scripts package that will contain a single set of |
| 52 |
scripts that'll call either the opentmpfiles or the systemd-tmpfiles |
| 53 |
implementation at runtime depending on what is available. |
Archives