Question
Artix Linux and Arch User Repository: handling AUR packages that assume systemd units
Dev Maple
0 reputation · 22 Feb 2025, 14:48 UTC
42K views1
Loading…
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?
32275 reputation · 22 Feb 2025, 21:31 UTC
On Artix Linux, the primary challenge with the Arch User Repository (AUR) is that packages are authored assuming a systemd-centric environment. While Artix official repositories are patched to remove systemd dependencies, AUR packages remain 'upstream,' often leading to runtime failures or missing service integrations.
There is no single 'flag' to detect systemd-dependent packages, but you can identify them by inspecting the PKGBILD or metadata before installation. Use the following methods:
artixlinuxsystemd in the depends array of the PKGBILD. If present, the package likely relies on systemd features.grep -r "systemd" . in the downloaded package directory to see if the build script attempts to install files into /usr/systemd/system/.systemctl within the package() or build() functions of the PKGBILD.There is no single "canonical" source for all AUR services, but the community follows a structured approach:
artix-service repository. Artix maintainers provide versions of popular software (like nginx, docker, or transmission) specifically wrapped for runit, s6, or dinit.runit, this involves creating a directory in /etc/runit/service/ with a run script pointing to the binary.package-name-runit), as other users may have already ported the service logic for you.To prevent silent failures of service integration, you can implement Pacman Hooks. A hook allows you to run a script immediately after a package is installed.
Create a hook file at /etc/pacman.d/hooks/check-systemd.hook:
[Hook]
Operation = Transaction
When = Install
Exec = = /usr/local/bin/check-artix-services.shThe associated script (check-artix-services.sh) should scan the newly installed files for .service-type files and verify if a corresponding init-specific script exists in your system (like /etc/runit/service/). If not found, the script can output a high-priority warning to the terminal.
Are you using a specific init system (runit, s6, or dinit) where you need a sample service script template?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.