Updating Your System

Config updates are merged with what's already in $HOME, not copied over it. The same mechanism runs on first boot and every time you ask for it later.

Sobarch's default dotfiles live in a package (sobarch-skel) rather than being copied once and forgotten. Every time it's applied, whether on first boot or whenever you ask for it afterward, it merges into your $HOME using a three-way comparison for each file:

• Your current copy in $HOME
• The baseline, a record of what was applied last time
• The new version being deployed

A file merges automatically wherever only one side actually changed. When both your copy and the new version changed the same file, that's a genuine conflict: the new version is dropped next to it as <file>.sobarch-new, and your real file is never touched.

Running it yourself

From the desktop: Super → Sobarch → Update System. It brings the whole system current in one run, with a progress notification throughout:

1. The Arch news feed is checked first. If items were published since your last successful update, they are listed and you choose whether to go on: some updates need a manual step first. An unreachable feed doesn't block the update. snap-pac snapshots the root filesystem around the pacman -Syu transaction, so a bad update can be rolled back (see Snapshots).
2. pacman -Syu updates official packages.
3. The package sync mechanism updates vendored AUR/custom packages. Packages the base system requires that were added after your install are picked up here too.
4. If sobarch-skel or sobarch-scripts was updated, boot and login theming is re-applied, so branding changes ship through this same command as config changes.
5. The merge described above runs, then your tinty templates are rebuilt, and you are walked through any conflicts interactively: Keep yours, Use the new version, view the Diff, Edit, Skip for now, or use the new version for All remaining conflicts.
6. A short sanity check reports anything left wrong: failed units, and a kernel update that needs a reboot. On UEFI installs, an earlier step also verifies that the Limine binary in /boot/EFI/BOOT matches the installed one, and warns if it doesn't. When all is well, the check says nothing.

You don't have to remember to run it: a daily check shows a notification when updates are waiting, and clicking it starts this same flow. You'll be asked to authenticate once for the package steps. If the update fails (offline, or a package conflict that needs a terminal), you get a notification saying which half failed, and the config merge still runs against whatever is already installed. Running pacman -Syu yourself from a terminal still works exactly as before; the pacman hook keeps vendored packages current in that case too.

From a terminal or over SSH (see The sobarch Command): sobarch update runs the same steps with plain prompts instead of menus (sudo for the package steps, and the conflict choices are typed as a letter). sobarch review-conflicts is the terminal equivalent of Review Conflicts below. Run both as your own user, not with sudo in front.

If you'd rather just revisit conflicts left over from a previous run without re-checking everything else, use Review Conflicts instead. It re-runs the same interactive walkthrough over whatever .sobarch-new files are still sitting on disk.

Testing the develop branch

Updates normally come from the master branch, which only changes when a release is cut. Day-to-day work lands on develop first. Testers and advanced users can follow it instead:

sobarch channel            # prints stable or develop
sobarch channel develop    # follow the nightly branch
sobarch channel stable     # back to master

develop is unsupported and can break. Take a snapshot before switching, and mention the channel in bug reports (sobarch doctor prints it). Switching back to stable does not downgrade anything already updated from develop: it only stops following it, so restore a snapshot if you need the old versions back. The command asks for confirmation when you leave develop, and --yes skips the prompt.

To install from develop, pass the flag through the usual bootstrap command:

curl -fsSL <bootstrap-url> | bash -s -- --channel develop

The installed system records develop and keeps following it. An ISO built from develop, or an installer run from a develop git checkout, does the same.

Edit this page on GitHub