Hi,

I would like to propose the following addition to §9.3:

========================================================================
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 3928723..45ad4d0 100644
- --- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -362,7 +362,13 @@ The ``sysv-rc`` runlevel system for ``sysvinit`` uses symlinks in
``/etc/rcn.d`` to decide which scripts to run and in which order at boot
time and when the init state (or "runlevel") is changed.  See the
``README.runlevels`` file shipped with ``sysv-rc`` for implementation
details.

[-Other alternatives might exist.-]{+``openrc`` can determine its own order of services to run and when to change+}
{+the init state. Since openrc uses ``/etc/rc/ìnit.d`` as service directory+}
{+but has its own service syntax divergent to ``sysvinit``, the following sections+}
{+about init scripts do not apply when using ``openrc-native``. Native openrc services+}
{+must be installed to ``/etc/rc/init.d``.+}

The sections below describe how to write those scripts and configure those
symlinks.

=========================================================================

Right now, in Debian, openrc still uses sysv init scripts for most
services. Based on initial work by leepen I improved the openrc-native
package which uses openrcs' native services and init to boot. This is
still very experimental (and not yet available), but can already
sucessfully boot a minimal Debian system to a tty and restart. This does
not depend on any sysvinit packages (in fact conflicts them). After
discussion with upstream I think it is best
to install the service files to /etc/rc/init.d, to avoid any kind of
conflict. E.g. openssh-daemon still ships an init script in /etc/init.d;
under openrc-native, this does not work (as it should). Even if one
tries to start a sysvinit script under openrc-native manually, this just
fails gracefully.

Another possibility would be for the services to live under /usr/, but
this would require coordination with upstream. I opened this bug mostly
to get a discussion going and to determine the best path for the
services.

I have been using openrc as init on my main machine for three years
without any problems. I acknowledge that Debians' main init is still
systemd (and not aiming to change that), but would like to improve
openrc support.

My proposed patch can also be found at
https://salsa.debian.org/werdahias/policy/-/tree/openrc?ref_type=heads

best,

werdahias


- -- System Information:
Debian Release: forky/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 7.0.7+deb14-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-jquery             3.7.1+dfsg+~3.5.33-1
ii  libjs-sphinxdoc          9.1.0-4
ii  sphinx-rtd-theme-common  3.1.0+dfsg-1

Versions of packages debian-policy suggests:
pn  doc-base  <none>
-----BEGIN PGP SIGNATURE-----

iIsEARYKADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCahxjehUcd2VyZGFoaWFz
QGRlYmlhbi5vcmcACgkQ7L7btge5sr41UwEA5mFT2AMcj4jxBlUgJ/M9e5lulAlL
hMPS03jkLXGpjc4A/2V7mNcf/dqhAg4O8VnWOhmqclk4IRj8p2WnswOnG9MB
=Mvqy
-----END PGP SIGNATURE-----

...

Please bear in mind that if the services are in /etc, then they will
remain on the system when a service is removed-but-not-purged, and need
to be carefully written to not break boot in that situation. This is one
of the ongoing problems with LSB /etc/init.d scripts: it has been worked
around in recent dh_installinit versions by chmod'ing them -x on package
removal, but that's extra maintainer-script code that ideally wouldn't
have been necessary.

Similarly, if OpenRC services have metadata similar to the LSB "INIT
INFO" section, and there is a bug in that metadata in the service left
behind by a package that has been removed, there's no Policy-compliant
way to fix that bug. In the past we've had situations where some
semi-related package has to ship a non-Policy-compliant maintainer
script to delete a broken init script, because otherwise it would have
broken upgrades.

I think putting the equivalents of init scripts and systemd services in
/usr with a mechanism for overrides in /etc, similar to how systemd
services were done, would be a good choice for new init systems.

     smcv

Right, that makes sense. I have talked with upstream, and they would
also be willing to support /usr/ with overrides in /etc/. Since this is
still being worked on, for the time being I would leave this for now,
and revisit once that change has landed in unstable.

best,

werdahias

So upstream already implemented this in
https://github.com/OpenRC/openrc/pull/942.

Does the following change sound good?



========================================================================
diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
index 3928723..45ad4d0 100644
- --- a/policy/ch-opersys.rst
+++ b/policy/ch-opersys.rst
@@ -362,7 +362,13 @@ The ``sysv-rc`` runlevel system for ``sysvinit`` uses symlinks in
``/etc/rcn.d`` to decide which scripts to run and in which order at boot
time and when the init state (or "runlevel") is changed.  See the
``README.runlevels`` file shipped with ``sysv-rc`` for implementation
details.

[-Other alternatives might exist.-]{+``openrc`` can determine its own
order of services to run and when to change+}
{+the init state. Since openrc uses ``/usr/libexec/rc/ìnit.d`` as
service directory+}
{+but has its own service syntax divergent to ``sysvinit``, the following sections+}
{+about init scripts do not apply when using ``openrc-native``. Native openrc services+}
{+must be installed to ``/usr/libexec/rc/init.d``.+}

The sections below describe how to write those scripts and configure those
symlinks.

=========================================================================

Thoughts on this?

best,

werdahias

Matthias Geiger [03/Jun  9:19pm +02] wrote:

Will the "must" requirement here make any packages in the archive buggy?

If we decide on this change, then none. openrc-native is a bin-NEW
package that then would need to comply with this. Plus any future
packages shipping such services.

best,

werdahias

One other option would be /usr/lib/rc/init.d. Mark, what do you think?

best,

werdahias

On Thu, 04 Jun 2026 17:48:32 +0200 Matthias Geiger <werdahias@riseup.net> wrote:
I think /usr/lib/rc/init.d will be a sane choice. Regardless, after some
more discussion, it turns out we need to wait on upstream to release
0.64 first, which will enable services being started from any path.

Thus setting moreinfo and upstream for now.

best,

werdahias