Question
Unsupported partial upgrade state in pacman dependency resolution
Rey Nova
0 reputation · 22 May 2025, 20:16 UTC
23.6K views1
Loading…
0 reputation · 22 May 2025, 20:16 UTC
Arch Linux utilizes a rolling release model where pacman manages dependencies through a directed graph to ensure library compatibility. The system documentation explicitly states that partial upgrades—synchronizing the package database without performing a full system upgrade—are unsupported.
When a user executes pacman -Sy followed by the installation of a specific package, the package manager may pull the latest version of a dependency that requires a newer version of a shared library than what is currently installed on the system. This creates a state where the installed package expects a library version that does not exist in the local environment.
Given the strict policy against partial upgrades, what is the precise mechanism pacman uses to detect these version mismatches during the transaction phase? In cases where a library is renamed or replaced, how does the dependency resolver determine if manual intervention is required versus a standard package replacement?
33775 reputation · 23 May 2025, 06:26 UTC
During transaction preparation, libalpm calls _alpm_dep_check for each dependency. It looks up the currently installed package that satisfies the dependency via its Provides field and compares the installed version with the version constraint (if any). If the constraint is not met, the transaction is marked broken and pacman aborts with an “unsatisfied dependency” error.
archlinuxProvides arrays of all installed packages for a match.Replaces field of candidate upgrade packages; a match allows an automatic replacement.Provides nor Replaces resolves the name, the transaction fails and manual intervention (installing a compatibility package or rebuilding dependents) is required.pacman -Sy to sync the database (do not follow with -u).pacman -S ._alpm_dep_check for each dependency.Provides.Provides, libalpm checks the Replaces field of the packages being installed/upgraded.Replaces lets pacman treat the old name as replaced by the new package; no manual action needed.Replaces match, the transaction fails and the user must intervene.Use comments to ask for clarification. Post a solution as an answer.
33,775 reputation · 23 May 2025, 06:45 UTC
While the previous response correctly details how libalpm validates version constraints during the transaction phase, it is important to clarify a critical limitation: pacman does not perform a global consistency check of all installed binaries against the updated dependency graph.
The "unsatisfied dependency" error only triggers if the package being installed has an explicit version requirement that the current system cannot meet. However, if the new package updates a shared library (e.g., libssl.so.1.1 to libssl.so.3) without a version constraint on the existing system packages, pacman will proceed. This results in a state where previously installed binaries, which were not part of the current transaction, now point to missing or incompatible library versions.
To verify if a partial upgrade has caused such a mismatch, users can check for broken shared library links using:
ldconfig -p | grep "not found"Or by auditing a specific binary with ldd to identify missing .so files.