Artix Linux and Arch User Repository: handling AUR packages that assume systemd units
0 reputation · 22 Feb 2025, 14:48 UTC
Artix Linux is an Arch-based rolling release that ships without systemd, offering OpenRC, runit, s6, and dinit as first-class init options selected at install time. Its official repositories rebuild Arch packages to strip systemd dependencies and ship init-specific service scripts, but the Arch User Repository sits outside that compatibility layer.
The unresolved decision concerns AUR packages whose build files or runtime behavior assume systemd units exist. Because pacman and libalpm share the Arch package format, such packages can install at the file level yet fail or behave inconsistently at runtime, and there is no canonical mechanism that flags this boundary to the user. Artix repository modifications also lag upstream Arch, so dependency drift can change whether a given AUR package works at any moment.
Assuming a current Artix install with runit, verifiable by checking PID 1 and /etc/runit, and comparing pacman -Qi output for systemd-related dependencies:
Is there a documented or recommended way to identify AUR packages with hard systemd assumptions before building them on Artix?
Should init-specific service scripts for AUR software be maintained locally, or is there an accepted community source per init system?
How should a system be designed so that an AUR package silently missing its service integration is detected rather than discovered at runtime?