Understanding Artix Linux’s artix-archlinux-support Repository: Design and Safe Usage

Problem

Artix Linux users want to install software from the Arch Linux binary repositories without introducing systemd, which conflicts with Artix’s init‑system‑agnostic goal. Directly using Arch packages brings systemd dependencies that can break services or leave the system partially systemd‑dependent.

Requirements

1. Binary compatibility with Arch packages so that installed software behaves identically.
2. Timely receipt of security updates from Arch.
3. Preservation of original package functionality after replacing systemd units.
4. Clear separation from Artix’s native repositories to avoid accidental mixing.

Smallest Suitable Design

The artix-archlinux-support repository implements a rebuild pipeline:

• Fetch the latest Arch PKGBUILD.
• Replace any systemd service files with equivalents for OpenRC, runit, or s6 (chosen per package).
• Adjust the depends array to drop systemd and add the chosen init‑system packages if required.
• Run the build in a clean chroot, sign the resulting package with the Artix master key, and publish it under a separate repo name.

Trust and Data Boundaries

Trust is placed in two entities:

• Arch Linux maintainers for providing correct, secure PKGBUILDs.
• Artix maintainers for correctly adapting those PKGBUILDs.

The boundary is the repository interface: users pull packages only after verifying the Artix signature, which isolates untrusted builds from the system.

Operational Checks

Before a package is released, the pipeline performs:

1. Signature verification of the source PKGBUILD (Arch’s upstream signature is not used; trust is implicit).
2. A diff‑based dependency audit: pacman -Qi on the rebuilt package vs. the original Arch package to confirm that systemd is absent and appropriate init‑system packages are present.
3. Installation of the package into a clean chroot and execution of its init‑script equivalents to ensure services start correctly.

Failure Modes

• Lagging behind Arch: If the rebuild pipeline is delayed, users may miss security patches or new features, exposing them to known vulnerabilities.
• Incorrect unit substitution: Mistakenly removing a systemd unit without providing a functional OpenRC/runit/s6 replacement can cause service startup failures, leading to boot issues or missing daemons.
• Signature mismatch: A corrupted or tampered package will fail pacman’s signature check, preventing installation but requiring user intervention to resolve.

Conditions That Would Change the Design

• If Arch moves to a split‑package model where systemd is optional upstream, the rebuild step could be eliminated.
• Should Artix adopt a universal init‑system abstraction layer that can translate systemd units at runtime, the static replacement approach might become unnecessary.
• A change in the Artix signing infrastructure (e.g., moving to a delegated key per repository) would alter the trust boundary and verification steps.

Example: Enabling the Repository and Installing vim

Assume you have administrative rights on an Artix system.

1. Import the Artix master key (replace <ARTIX-MASTER-KEY> with the actual key ID from the Artix wiki):

   sudo pacman-key --recv-keys <ARTIX-MASTER-KEY>
   sudo pacman-key --lsign-key <ARTIX-MASTER-KEY>

2. Add the repository to /etc/pacman.conf:

   [artix-archlinux-support]
   SigLevel = Required DatabaseOptional
   Server = https://mirror.artixlinux.org/repos/archlinux-support/$arch

3. Refresh the package databases:

   sudo pacman -Sy

4. Install vim from the support repo:

   sudo pacman -S vim

Expected checks: After installation, run pacman -Qi vim and verify that the Depends On line does not list systemd and that any init‑system dependencies (e.g., openrc) are present. Confirm that pacman -Qk vim reports zero missing files.

Risks: If the key import fails, pacman will reject all packages from the repo with a signature error. Do not disable signature checking; instead, verify the key ID from official Artix documentation.

Verification Steps

1. Enable the repo as shown above.
2. Install a test package (e.g., bash) from the repo.
3. Run pactree -s bash on both the Arch original and the Artix‑supported version to compare dependency trees; the Artix version should lack systemd.
4. Check the package signature: pacman-key --verify /var/cache/pacman/pkg/artix-archlinux-support/bash-*.pkg.tar.zst.sig should return a good signature from the Artix master key.

Limitations

• The repository only covers packages that have a direct systemd dependency; packages that optionally recommend systemd may still pull it in as a soft dependency.
• Build latency means there is a window between an Arch release and the availability of the rebuilt package.
• Some packages require patches beyond unit replacement (e.g., hardcoded paths to /usr/lib/systemd); those are handled case‑by‑case and may still exhibit minor differences.

Rollback

Enabling the repository and installing packages changes system state. To rollback:

1. Remove the installed support packages: sudo pacman -Rns $(pacman -Qqm | grep '^artix-archlinux-support-')
2. Comment out or delete the [artix-archlinux-support] section in /etc/pacman.conf.
3. Refresh the sync databases: sudo pacman -Sy

This returns the system to using only Artix’s native repositories and any previously installed Arch packages will need to be replaced with Artix‑native equivalents if they remain.