How Artix Linux Keeps One Package Base Running on OpenRC, runit, and s6

Picking an init system for an Arch-based distro usually means picking a set of service files that match it. Artix Linux wants to offer OpenRC, runit, and s6 without maintaining three completely separate package trees. The practical solution is init-specific repositories plus split service subpackages built from a single upstream PKGBUILD.

The problem with one PKGBUILD and three inits

Upstream Arch packages assume systemd unit files. On Artix, a service like cronie or nginx must provide an OpenRC init script, a runit supervise directory, or an s6 service bundle, depending on the user’s choice. Shipping all three in one package creates file conflicts and unnecessary dependencies. Shipping none forces users to write wrappers.

Artix resolves this by treating the init system as a distribution profile. There are three installation media and three repository sets: one for OpenRC, one for runit, one for s6. The same upstream source is used, but the build produces init-appropriate service artifacts.

Separate repos, shared upstream

Each profile has its own repository branch. Packages are built from the Arch base and then processed by Artix tooling, commonly referred to as artools, which automates building and testing across the three profiles. The goal is consistency without manual duplication.

On an installed system you can verify which profile is active by checking base packages. Run as root:

pacman -Q openrc runit s6-base

Expected checks: only the base packages for the chosen profile are installed. The presence of openrc indicates the OpenRC profile, runit indicates the runit profile, s6-base indicates the s6 profile. Mixing packages from different profile repositories can lead to missing service files or dependency conflicts because pacman does not automatically resolve cross-init dependencies.

Repository identity is defined in /etc/pacman.conf. A practical verification step is to confirm the [core], [extra], and [community] entries point to the same init profile. Changing the profile later by installing the other init’s base packages is possible, but a clean reinstall is recommended due to deep integration differences.

Split service packages in practice

Service-providing packages use split packages for init scripts. A single PKGBUILD can define a main package with binaries and libraries, plus optional subpackages such as cronie-openrc, cronie-runit, and cronie-s6. The main package stays init-agnostic; the subpackages install the service definition and declare a dependency on the init base.

Example structure for a service package:

• Main package: installs binaries, config, man pages.
• openrc-service subpackage: installs /etc/init.d/cronie and a dependency on openrc.
• runit-service subpackage: installs /etc/runit/sv/cronie and a dependency on runit.
• s6-service subpackage: installs /etc/s6/services/cronie and a dependency on s6-base.

You can inspect what is installed for a given service on your system:

pacman -Qi cronie-openrc

Run as root. Expected checks: the package description shows the init dependency and the files list points to the init-specific directory. If you are on the runit profile, the installed service package should be cronie-runit, not cronie-openrc.

This split model means the Artix build infrastructure can generate three repository variants from one source without maintaining three PKGBUILDs.

Trade-offs and how to stay safe

Limitations are real. Third-party AUR packages often assume systemd and may require manual adaptation to work with OpenRC, runit, or s6 service management. The rolling-release nature also means init system updates can introduce breaking changes in service syntax or dependency ordering, for example changes in OpenRC 0.50+ handling.

Practical safety checks:

• Keep all packages from the same profile. Do not enable a second Artix repository branch in pacman.conf.
• After an upgrade, verify service availability in the correct location: /etc/init.d for OpenRC, /etc/runit/sv for runit, /etc/s6/services for s6.
• When evaluating an AUR package, check for init-specific install scripts before building.

The actionable takeaway is to treat the init profile as part of the distribution identity. Choose the profile at install time, keep the repositories aligned, and rely on the split service subpackages to provide the correct service definition for that profile.