Manjaro SafeAUR Updater: use the AUR without breakage

Fix a specific problem

AUR package broken after a Manjaro update"error while loading shared libraries", stranded python packages, and finding everything that needs a rebuild. "could not satisfy dependencies" with chaotic-aur or BlackArchWhy foreign repos outrun Manjaro, and how to hold the right package back.

The gap nobody supports

The AUR assumes you are current with Arch. Manjaro's Stable branch deliberately trails Arch by roughly two weeks. Manjaro's own forum says the AUR is used "at your own risk and your own responsibility". That's fair, but knowing the risk is yours only helps if you can see it.

Failure	When it bites	What closes it
Partial upgrade. A foreign binary repo (BlackArch, chaotic-aur) rebuilt a package against Arch's newer library; installing it drags in a dependency Manjaro can't satisfy yet.	While Manjaro is behind	`safeup` holds only the foreign upgrades whose version-constrained dependencies can't be met yet, and logs every hold.
Stale soname. Manjaro ships the new library, and AUR packages built against the old one die at runtime.	When Manjaro catches up	`aur-rebuild-check` names every AUR package that needs rebuilding, python bumps included.
Unpinned VCS source. `git+https://…` with no commit: what builds today isn't what you audited.	Any install or upgrade	`aur-pin-check` refuses VCS sources not pinned to an immutable revision.

Quick start

git clone https://github.com/doug445/manjaro-safeaur-updater.git
cd manjaro-safeaur-updater
./deploy.sh

safeup                 # pacman -Syu, with the partial-upgrade guard
safeup --check         # what it would do: no root, nothing changed
safeup --aur           # repo upgrade, then AUR updates, then the rebuild scan
aurinstall <pkg>       # yay -S behind the pin-check gate, built in a chroot when possible
aurupdate              # yay -Sua behind the pin-check gate
aur-rebuild-check      # what needs rebuilding after a library or python bump

deploy.sh asks before installing any missing dependency, and it is idempotent: anything it replaces is backed up first.

"But this automates `pacman --ignore`"

It does, and that deserves a real answer. --ignore suppresses an upgrade, not dependency resolution. pacman still resolves the whole transaction and refuses one that would leave a dependency unsatisfied, changing nothing. The project tests that against real pacman on every push rather than asserting it, because the whole safety argument rests on it. The partial-upgrade guide shows the transcript.

Builds against the libraries you actually run

aurinstall builds in Manjaro's own manjaro-chrootbuild by default. linux-aarhus of the Manjaro team suggested it. The chroot is synced to your Manjaro branch, so the package links against the libraries you run rather than whatever the AUR assumed. That fixes stale-soname breakage at build time. AUR dependency chains are built dependencies first, and every link in the chain is pin-checked.

What it does not do

It doesn't make Manjaro track Arch. If you want Arch's timing, run Arch.
It doesn't audit what a PKGBUILD does. Pinning proves you build the commit you reviewed, not that the commit is benign.
A chroot is build isolation, not a security boundary.
It doesn't replace backups or snapshots.

FAQ

Why does the AUR break things on Manjaro?

The AUR assumes you are current with Arch, and Manjaro's Stable branch deliberately trails Arch. Packages built against Arch's newer libraries can need dependencies Manjaro does not have yet, and when Manjaro catches up, AUR packages you built against the older library stop resolving it.

Doesn't automating pacman --ignore cause partial upgrades?

No. --ignore suppresses an upgrade, not dependency resolution: pacman still resolves the whole transaction and refuses one that would leave a dependency unsatisfied. The project's test suite proves this against real pacman transactions on every push.

Does it work on Arch Linux?

It is scoped to Manjaro on purpose. The problem it solves is created by Manjaro's Stable branch trailing Arch; on Arch itself there is no lag to guard against.

Does it make the AUR safe?

No. Pinning proves you build the commit you reviewed, not that the commit is benign, and a chroot is build isolation, not a security boundary. Read the PKGBUILD. The AUR is not supported by Arch or Manjaro.

Not for beginners: everything here assumes you can read a PKGBUILD and recover your own system. The project's README says how it was built, AI assistance included.