Learning Artix Linux - Rolling Release & Testing Repositories

#Introduction

You've run pacman -Syu many times by now. Episode 17 explains what actually happens behind Artix's rolling release model, the difference between stable and testing repositories, and how mirrors synchronize packages around the world.

Understanding this model isn't just knowledge: it determines when you should update, why updates are sometimes risky, and how to use testing repositories safely. This is the knowledge that makes you read release news wisely.

#The Rolling Release Model

#Continuous, Not Staged

Unlike point releases like Ubuntu or Debian, Artix has no versions — the system is updated continuously. Packages that pass testing land in the stable repo and become immediately available to all users. You always run the latest software, and updates happen via pacman -Syu at any time.

The consequence: there's no "major upgrade" that drastically reshapes the system, but every update brings small changes continuously. This is why routine backups (episode 16) and reading release news are mandatory habits.

#Verifying the Model

Check the age of installed packages to see how fresh the rolling release is:

pacman -Qi kernel | grep 'Build Date'
uname -r

The output of pacman -Qi kernel shows the package build date. On a rolling system, this date is usually very close to your last update.

#Stable and Testing Repositories

#base, world, and galaxy

The repository structure was introduced in episode 2. Now look at how it works from the update side: base holds the system foundation, world holds most applications, and galaxy holds community packages. All three are considered stable and safe to use.

List the active repos with:

pacman-conf --repo-list

pacman-conf --repo-list shows all repositories defined in /etc/pacman.conf, including commented-out ones.

#Testing Repositories

Artix provides testing repos: world-testing and galaxy-testing. Packages here are new versions still under testing — they may be unstable, have immature dependencies, or require reconfiguration. Enable them only if you're ready to face the consequences:

[world-testing]
Include = /etc/pacman.d/mirrorlist
 
[galaxy-testing]
Include = /etc/pacman.d/mirrorlist

After enabling, run a full update:

sudo pacman -Syu

The pacman -Syu command now includes testing packages. Note that enabling testing means much of the system can follow updates into unstable versions.

#When to Use Testing

Only use testing for a specific reason: trying a new feature, waiting for a particular bug fix, or helping the project report issues. For production machines, leave the testing repos off. Users who just want the newest software should wait for packages to reach stable.

#Package Promotion Order

#From Testing to Stable

Artix's workflow goes roughly like this: developers build and test a package, put it in a testing repo, then once it's considered stable, move it to a stable repo. This provides a layer of assurance before packages reach general users.

A rarely noticed consequence: a stable package can "revert" to an older version if the testing version proves problematic. Don't panic when that happens — it's actually a sign the quality process is working.

#Reading Release News

Artix announces major changes at artixlinux.org/news. A recommended habit before updating: read the latest news. If there's an announcement about configuration changes or kernel issues, update with the appropriate preparation:

curl -s https://artixlinux.org/news.php

curl -s https://artixlinux.org/news.php pulls the news page. This small step prevents surprises when a major update arrives.

#Mirror Synchronization

#The Tier 1 and Tier 2 Hierarchy

Artix mirrors are organized in tiers. Tier 1 syncs directly from the main servers and is the freshest; Tier 2 pulls from Tier 1. The higher the tier, the smaller the potential package lag. Every mirror has a publicly monitorable status.

#Choosing the Right Mirror

The right mirror means fast downloads and fresh packages. Generate a mirrorlist with artix-mirrorlist based on your location:

artix-mirrorlist -l id,sg,my

After choosing, verify your mirror isn't lagging by comparing lastupdate:

curl -s http://mirror/artix/lastupdate

The output of curl -s http://mirror/artix/lastupdate is the last synchronization timestamp. A mirror whose lastupdate is days behind will have you updating stale packages — switch mirrors if that happens.

#Conclusion

Episode 17 explained Artix's rolling release model: continuous updates, the stable base/world/galaxy repositories, the optional and risky testing repositories, the package promotion order, and how mirrors work with a tier hierarchy and lastupdate verification.

Key takeaways:

• Rolling release means continuous updates, with no major release versions.
• world and galaxy are stable; world-testing and galaxy-testing are risky.
• Testing is only for those ready to face instability.
• Packages can "revert" to older versions if a new one is problematic.
• Read release news before major updates.
• Choose fresh mirrors via lastupdate; Tier 1 is the fastest.

In the next episode, episode 18, we'll cover systemd service migration — understanding systemd's roles, its replacements on Artix (eudev, elogind, D-Bus), translating units to init scripts, and why systemd-dependent services fail.