Manjaro SafeAUR Updater › Partial upgrades

Manjaro “could not satisfy dependencies” with chaotic-aur or BlackArch

You have chaotic-aur, BlackArch or another third-party binary repository enabled, and pacman -Syu stops with error: failed to prepare transaction (could not satisfy dependencies), or tells you that installing one package breaks a dependency required by another. This page explains what the message means, why Manjaro hits it when Arch does not, the manual ways out that do not make things worse, and exactly how far --ignore can be trusted.

What the error means

It comes in two forms, and both are pacman refusing a transaction before it changes anything. pacman may print warnings above them; the lines that matter look like this, with placeholder package names:

error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libfoo>=2.0' required by bar

The new version of bar, usually from your third-party repository, needs libfoo 2.0 or later. Nothing installed provides it, and nothing in this upgrade will.

error: failed to prepare transaction (could not satisfy dependencies)
:: installing libfoo (2.0-1) breaks dependency 'libfoo=1.0' required by bar

This is the other direction. Upgrading libfoo would leave an installed package, bar, with a version requirement it no longer meets. bar is often a foreign or AUR package built against the old version.

“Failed to prepare transaction” means pacman stopped before downloading or installing any package. The -y half of -Syu, however, has already run: your sync databases are now newer than your installed packages. The Arch wiki’s rule for this state is that the error “must be resolved and the upgrade operation completed before other package management operations.” In particular, do not pacman -S anything else until you have.

Why Manjaro hits this and Arch does not

chaotic-aur and BlackArch build against Arch’s repositories and publish as soon as Arch moves. Manjaro’s branches do not move with Arch: Unstable “is synced several times a day with Arch package releases”, while packages reach Stable only after “roughly a couple of weeks testing by the users of the Unstable/Testing repos”.

So for a while the third-party repository’s bar is built for Arch’s libfoo 2.0 and Manjaro’s repository still carries libfoo 1.0. On Arch the two arrive together. On Manjaro there is a gap, and every pacman -Syu during it asks pacman to install a package whose dependencies your repositories cannot meet yet. The How-To Geek article quoted in the sources describes the same mismatch for AUR packages.

The same gap causes the opposite problem later: AUR packages built against libfoo 1.0 break when Manjaro ships 2.0. That is covered in AUR package broken after a Manjaro update.

Find out which package is stuck

To see what is pending without touching the sync databases, use checkupdates from pacman-contrib, which both the Arch and Manjaro wikis recommend for this:

checkupdates

Then compare what bar wants with what you have and what your Manjaro repositories offer:

pacman -Si bar
pacman -Si libfoo
pacman -Qi libfoo

pacman -Si bar shows the Repository it comes from and its Depends On line with the version constraint. If more than one repository carries the name, it prints one block per repository; the first, in pacman.conf order, is the copy -Syu installs. pacman -Si libfoo shows the newest version your repositories offer, and pacman -Qi libfoo shows the installed version and what requires it. If the version bar needs is newer than anything Manjaro offers, you are looking at the lag, not a broken mirror.

Safe ways out

Wait

When Manjaro ships libfoo 2.0, a plain pacman -Syu installs both together and the error goes away. The cost is that until then pacman -Syu keeps stopping at this error, so you get no other updates either. That is why most people reach for the next option.

Hold the new version of the dependent package, for one upgrade

sudo pacman -Syu --ignore bar

--ignore takes a comma-separated list and applies to this one command, unlike IgnorePkg in pacman.conf, which applies until you remove it. bar stays at the version you already have, everything else upgrades, and pacman still checks bar’s existing dependencies against everything that moves. Next time, run plain pacman -Syu again and see whether Manjaro has caught up.

This is a partial upgrade, and both wikis say so. The Arch wiki: “Be careful in skipping packages, since partial upgrades are unsupported.” Manjaro’s: “Don't add packages to pacman's or pamac's ignore list.” The reason for the rule is the Arch wiki’s own example: upgrading one package pulls in a new library, which “might then break the other package which depends on an older version of the library.” Holding a library while its dependents move forward is that pattern. Holding bar, the dependent whose new version cannot install correctly right now anyway, is the opposite direction: its old version keeps the dependencies it was already installed with.

Keep the hold visible. Write it down, and retry without --ignore after each Manjaro Stable update. A hold that quietly becomes permanent is the long-term hazard.

What not to do

Can --ignore leave a dependency unsatisfied?

Not a declared one. --ignore suppresses an upgrade; it does not suppress dependency resolution. pacman still resolves the whole transaction and refuses one that would leave a dependency unsatisfied. The manjaro-safeaur-updater README shows this as a test against a throwaway pacman root rather than an assertion: consumer 1.0 requires libX=1.0, both have upgrades pending, and libX is ignored so that consumer 2.0 would need a libX 2.0 that will not be installed.

$ pacman -Syu --noconfirm --ignore libX
warning: ignoring package libX-2.0-1
warning: cannot resolve "libX=2.0", a dependency of "consumer"
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libX=2.0' required by consumer
                                                            exit 1

$ pacman -Q                       # nothing moved
consumer 1.0-1
libX 1.0-1

$ pacman -Dk                      # pacman's own consistency audit
No database errors have been found!

Nothing moved, and pacman’s database check finds nothing wrong. The transcript is section 19 of tests/loopback-core-test.sh and runs in CI against real pacman transactions. It tests pacman’s behaviour, not any wrapper’s: if you --ignore the wrong thing, pacman refuses rather than installing a broken set.

Where that guarantee ends. pacman checks the dependencies packages declare. It cannot see a soname recorded inside a binary unless the package also declares it as a dependency. The guarantee is only as strong as the packages’ metadata, which is why the direction of a hold still matters. And any tool that automates --ignore inherits this property rather than adding to it: you are trusting pacman’s resolver, not the tool.

Automating the hold

Automated: safeup, from manjaro-safeaur-updater, makes this decision before pacman -Syu rather than after it fails. It reads your repositories from pacman.conf and treats any that is not core, extra, multilib, community, core-testing, extra-testing or multilib-testing as foreign; with none, it passes straight through to plain pacman -Syu. Its pre-flight refreshes a private snapshot of the sync databases, the way checkupdates does, so your real database is never refreshed without an upgrade. For each pending upgrade it judges the copy pacman will actually install, the first repository in pacman.conf order that carries it. If that copy is foreign, each version-constrained dependency must be satisfied either by what is installed (pacman -T) or by a package this same upgrade brings in (pacman -Sddp). A package that fails both is held with --ignore, and everything else upgrades in one pacman -Syu.

If pacman still reports installing X breaks dependency … required by Y, safeup adds X to --ignore and retries, up to three times, so one ABI break does not block the whole upgrade. Here X is whatever pacman was installing, which can be a library, and each retry is still resolved by pacman as a whole. Every hold is printed and appended to /var/log/safeup.log, so it stays a deferred upgrade you can chase. safeup --check lists pending upgrades and the holds a real run would make, without root and without changing anything (it needs fakeroot, from base-devel). After a successful upgrade it runs aur-rebuild-check.

The README states its limitation plainly: “safeup does not pre-check whether a package it holds is itself required by something else in the same transaction. It relies on pacman refusing, and then isolates the break.” It also cannot make Manjaro track Arch, or install a package that genuinely needs a newer library; holding it is the correct outcome. See What this does not do.

Questions

Is pacman --ignore a partial upgrade?

Yes. Skipping any package during pacman -Syu leaves your system on a mix of versions the repositories never shipped together, and both the Arch and Manjaro wikis warn against it. What --ignore cannot do is install a set of packages with an unsatisfied declared dependency: pacman resolves the whole transaction and refuses instead. The risk that remains is holding a library while the packages built against it move on, so hold the dependent package, for one upgrade, and retry without the hold next time.

Why do chaotic-aur and BlackArch break Manjaro but not Arch?

Both build against Arch’s current repositories. Manjaro Stable receives packages after roughly a couple of weeks of testing, so for a while the third-party package needs library versions Manjaro does not ship yet. On Arch the library and the rebuilt package arrive together.

Did the failed pacman -Syu change anything?

No packages changed: “failed to prepare transaction” means pacman stopped before installing anything. The database refresh did happen: the -y step already ran, so your sync databases are now newer than your installed packages. Resolve the error and complete a full upgrade before installing anything else with pacman -S.

How long until Manjaro catches up?

There is no fixed date. Manjaro’s wiki describes Stable packages as having gone through roughly a couple of weeks of testing on the Unstable and Testing branches. Retry a plain pacman -Syu after each Stable update and drop the hold as soon as it succeeds.

Should I switch to the Unstable branch to avoid this?

It narrows the gap, since Unstable is synced with Arch several times a day, but Manjaro-specific packages such as kernels enter there before they have been tested. That is a trade-off to make deliberately, and after switching branches you must sync and upgrade with pacman -Syu.

Sources