openrc support in init-system-helpers part 1

[Lorenzo]

Hi Matthias,

late reply but I'm still on vacation, I hope that few pointers are
better than nothing 

> One other issue I have the name. rc-service and openrc are already 
> taken; how would I name such a helper then?

looking at other helpers, it could be something like openrc-helper
(similar to runit-helper) or deb-openrc-helper (similar to systemd's
deb-systemd-helper) and/or deb-openrc-invoke ?

> implemented. To autostart services on package installation, we need 
> debhelper support, essential dh_installinit. 

not sure if the idea is to use dh_installinit for openrc, but I would
rather use dh_openrc or dh_installopenrc; developers will likely look
for an equivalent of dh_installsystemd and it would not be obvious that
openrc support is in dh_installinit; also openrc support would be
coupled to sysvinit (think if you want to ship a service disabled but
the sysvinit script is shipped as enabled)

> However, that in turn 
> requires init-system-helper support.

Yes and no: if you do like sysvinit and systemd, then yes; if you do
like runit and package and external helper like runit-helper, then
mostly no.
But keep in mind that, for purge operations, you would still need
an helper such as 'openrc-purge-helper' inside an essential package,
because purge happens at postrm and even if a foo-package depends on
your 'openrc-helper' package, such dependency is not guaranteed to be
installed after the foo-package has been removed..
So yes, is better if you manage to merge your openrc helper(s) into
init-system-helper.

> how I would reliably determine I was
> running under 
> sysvinit.

* detecting running init: i think the current way is
    if [ -d "/run/systemd/system" ]; then
        #systemd
    elif [ -f /run/openrc/softlevel ]; then
        #openrc
    elif [  -f /etc/runit/stopit ]; then
        #runit
    elif [ -p /run/initctl ]; then
        #sysvinit
    fi
   but look inside invoke-rc.d and or reportbug; note that order of
   testing matters: systemd had support for initctl pipe, so it had to
   be tested first; I would look for the running init rather than for
   an installed package, the latter has false positives, like during an
   init switch or if one starts a non default init at boot with the
   kernel command line

* consider the "old" policy-rc.d mechanism
  https://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt
  see also invoke-rc.d(8)
  you have to check for /usr/sbin/policy-rc.d (if exists) and when it
  returns 101 do nothing; example: you don't want to run/signal services
  during the installation process; you don't want to run services in a
  sbuild chroot.

* you likely want to design an override mechanism for sysvinit scripts:
  sysvinit script are run unconditionally (regardless or the running
  init) in maintscripts so if you have a native openrc service you end
  up with duplicate instances of the same service. So when there is a
  native openrc service you want to "mask" the init script.
  For example, I think systemd uses the 'invoke-rc.d
  --skip-systemd-native' flag; previously they used
  /usr/lib/lsb/init-functions.d/40-systemd
  (I strongly recommend against 40-systemd); runit has a configurable
  mechanism for each runscript, see
  https://salsa.debian.org/debian/runit/-/blob/master/debian/contrib/runit-default?ref_type=heads
  and
  https://salsa.debian.org/debian/runit/-/blob/master/debian/contrib/i-s-h/invoke-rc.d-runit.patch?ref_type=heads

> .
> Am I correct in assuming that this is where I would abstract all
> checks, such as only starting a openrc service if we are truly
> running a openrc system? 
> 
> I think most functionality would be a thin wrapper over rc-service,
> so I do not see a huge benefit there, but apparently this has to be
> done this way?

> Second, which command line flags to implement etc.

I will try to answer this tomorrow

> 
> current status is at codeberg.org/werdahias/rc-helper (arguably not 
> much). I will add some more details soon.
> 
> best,
> 
>