Fixing Broken Package Dependencies in Linux

1 Aug 2026

You try to install or update software in Linux, but the package manager stops with an error such as:

Unmet dependencies

Broken packages

Conflicting requests

Could not resolve dependencies

or:

Package requires a library version that cannot be installed

The desktop may still work normally, or the failure may prevent further updates from installing. In more serious cases, an interrupted upgrade can leave applications unable to start because the required libraries no longer match.

The correct repair depends on which Linux distribution you use and what caused the conflict. The safest approach is to refresh the approved repositories, complete any interrupted package configuration and allow the distribution’s own package manager to resolve the dependency chain.

Avoid solving the problem by downloading random library files or forcing package removal. Those shortcuts can turn one broken application into a damaged operating system.

What Is a Package Dependency?

Most Linux applications are split into packages.

A package may contain:

An application
A shared library
A driver
A command-line utility
Language support
Documentation
A desktop component
Development files

One package can depend on several others.

For example, a media player may require:

A graphical toolkit
Audio libraries
Video codecs
Certificate packages
A specific runtime version

The package manager tracks these relationships and normally installs everything automatically.

A dependency becomes broken when the required package is:

Missing
The wrong version
Unavailable from the enabled repositories
Being replaced by an incompatible package
Held back from upgrading
Installed for a different distribution release
Damaged by an interrupted update

Common Symptoms

Broken dependencies can cause:

Applications refusing to install
Updates failing repeatedly
Software opening with missing-library errors
The graphical software centre becoming unusable
Packages remaining “not fully installed”
The package manager reporting conflicts
One package demanding removal of another
Kernel modules failing after an update
Applications disappearing after a partial upgrade
The system booting but important services failing

The error message usually names at least one package involved. Record the complete message before trying repairs.

First, Identify the Package Manager

Different Linux families use different package-management systems.

Debian, Ubuntu and Linux Mint

Normally use:

apt

dpkg

Fedora and related systems

Normally use:

dnf

rpm

Fedora’s traditional editions use DNF for dependency-aware package installation and updates, while image-based Fedora editions use different tooling such as rpm-ostree.

Arch Linux and Manjaro

Normally use:

pacman

openSUSE

Normally uses:

zypper

rpm

Do not follow Ubuntu commands on Fedora or Arch commands on openSUSE. The package formats and repair methods are different.

Before Running Repair Commands

Take a few basic precautions:

Save your work
Connect the laptop to power
Confirm the internet connection is stable
Make sure the system drive has free space
Do not interrupt the package manager
Back up important files
Record any third-party repositories you recently added
Note any packages installed manually before the problem began

On a production server or business workstation, take a snapshot or verified backup where possible.

Check Available Disk Space

Package installation needs room for:

Downloaded packages
Temporary extraction
Package databases
New kernels
Logs
Previous package versions

Run:

df -h

Pay attention to:

and, where separate:

/boot

/var

A full /boot partition can prevent kernel updates. A full /var can stop package downloads or database updates.

Do not start deleting package-manager database files to create space.

Restart Before Deeper Repairs

An application or update service may still hold the package database lock.

Restart the computer and retry the update.

If the previous installation was interrupted by a crash or forced shutdown, restarting can also allow background services and mounted file systems to return to a normal state.

Do not repeatedly kill package-manager processes unless you have confirmed they are genuinely stuck rather than still working.

Debian, Ubuntu and Linux Mint Repairs

Refresh the Package Lists

Open Terminal and run:

sudo apt update

This downloads current package metadata from the configured repositories.

Read the output carefully. Repository errors may reveal the real cause, such as:

A repository no longer supporting your release
Duplicate repository entries
An invalid signing key
A network or DNS failure
A third-party source for the wrong Ubuntu release

APT can only resolve dependencies using packages it knows are available.

Complete Interrupted Package Configuration

If an installation stopped while packages were being configured, run:

sudo dpkg --configure -a

This asks dpkg to configure packages that were unpacked but not fully installed.

Ubuntu’s package-repair guidance includes dpkg --configure -a as a standard step when packages are left in a broken or unfinished state.

Allow it to finish before running another package command.

Ask APT to Repair Broken Dependencies

Run:

sudo apt --fix-broken install

The older equivalent is:

sudo apt-get -f install

APT will calculate which missing dependencies must be installed or which conflicting packages must be removed.

Review the proposed changes before confirming.

If it wants to remove a large part of the desktop, essential kernel packages or your main graphical environment, stop and investigate the repositories first.

Run the Normal Upgrade

After the repair completes:

sudo apt update

sudo apt upgrade

For dependency changes requiring package replacement or removal, the system may need:

sudo apt full-upgrade

Read the proposed removals carefully. full-upgrade can make broader dependency decisions than an ordinary upgrade.

Reinstall the Affected Package

If one package appears damaged:

sudo apt install --reinstall package-name

Replace package-name with the exact package.

For example:

sudo apt install --reinstall network-manager

Do not guess package names. Find the exact installed name with:

dpkg -l | grep keyword

Check Held Packages

APT allows packages to be placed on hold, preventing them from upgrading.

List held packages:

apt-mark showhold

A held library can block newer applications that require an updated version.

Remove a hold only when you understand why it was set:

sudo apt-mark unhold package-name

Then retry:

sudo apt update

sudo apt upgrade

On business systems, a package may be deliberately held for compatibility.

Inspect the Dependency Chain

To inspect a package:

apt-cache policy package-name

This shows:

Installed version
Candidate version
Available repository versions
Repository priority

To see its dependencies:

apt-cache depends package-name

These commands can reveal that the system is mixing versions from:

Different Ubuntu releases
Debian and Ubuntu
Stable and testing branches
Official and third-party repositories

Check Third-Party Repositories

Additional repositories are a common source of dependency conflicts.

Ubuntu supports third-party repositories, but they become part of APT’s available package sources and can provide versions that differ from the official distribution.

List configured sources:

grep -R --no-filename -h "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/

On newer systems, some entries may use .sources files rather than traditional .list files.

Look for sources associated with:

An older distribution release
A testing or development branch
An application you removed
A repository that no longer exists
Another Linux distribution
An unofficial mirror

Disable the suspected third-party source using the system’s Software Sources tool or by carefully editing the relevant source file.

Then run:

sudo apt update

sudo apt --fix-broken install

Do not delete every repository entry indiscriminately.

Avoid Installing Random

.deb

Files with

dpkg

Running:

sudo dpkg -i package.deb

installs that local package but does not always resolve its required dependencies automatically.

A safer modern approach is:

sudo apt install ./package.deb

APT can then attempt to obtain the required dependencies from configured repositories.

Ubuntu documentation warns that manually downloaded packages created for another distribution can create dependency problems and that careless use of dpkg can damage the package database.

Only install .deb packages intended for your exact architecture and distribution release.

Remove a Truly Incompatible Package

If a third-party application is blocking the entire package system, remove it through APT:

sudo apt remove package-name

To remove its configuration as well:

sudo apt purge package-name

Then run:

sudo apt --fix-broken install

Do not force-remove foundational packages such as:

libc6
systemd
apt
dpkg
The desktop meta-package
The running kernel

A seemingly small package may be required by many others.

Clean Downloaded Package Files

A damaged cached package may repeatedly fail.

Clear downloaded package files:

sudo apt clean

Refresh the lists and retry:

sudo apt update

sudo apt --fix-broken install

This does not remove installed applications. It removes cached package downloads.

Remove Unused Dependencies Carefully

After the system is repaired:

sudo apt autoremove

Review the list before confirming.

Do not use autoremove as the first repair step. When package states are already inconsistent, it may propose removing software you intended to keep.

Fedora Repairs

Refresh Metadata and Upgrade

On a traditional Fedora installation, start with:

sudo dnf upgrade --refresh

This refreshes repository metadata and attempts a full supported update.

DNF is designed to install, remove and update packages with automatic dependency resolution.

Review any conflict message before adding force-style options.

Synchronise Installed Packages with Repositories

If the system contains mismatched package versions, run:

sudo dnf distro-sync

This aligns installed package versions with those available in the enabled repositories.

Fedora’s upgrade guidance specifically recommends dnf distro-sync when a system is partly upgraded or showing dependency problems.

This command may downgrade a package when the enabled repository contains an older supported version.

Check for Duplicate Packages

Run:

sudo dnf repoquery --duplicates

Duplicate versions can remain after interrupted upgrades or repository changes.

Fedora’s documentation recommends checking for duplicates while diagnosing upgrade and dependency issues.

Do not manually erase RPM database files to remove duplicates.

Check Unsatisfied Dependencies

Run:

sudo dnf repoquery --unsatisfied

This identifies installed packages whose requirements are not currently satisfied.

The output can help determine whether the broken item belongs to:

Fedora itself
RPM Fusion
A COPR repository
A vendor repository
A manually installed RPM

Use

--allowerasing

with Caution

DNF may suggest:

sudo dnf distro-sync --allowerasing

or:

sudo dnf upgrade --allowerasing

This allows DNF to remove packages whose dependencies cannot be satisfied.

Fedora documents --allowerasing as an option that can resolve dependency problems by removing incompatible packages.

Read the removal list carefully.

Stop if it proposes removing:

The desktop environment
Networking components
The kernel
Security software
Important business applications

Reinstall a Package

Use:

sudo dnf reinstall package-name

This can repair damaged files while preserving the installed package selection.

Review Enabled Repositories

List repositories:

dnf repolist

Show all repositories:

dnf repolist --all

A repository built for a different Fedora version can create conflicts.

Temporarily disable a suspected repository for one command:

sudo dnf --disablerepo=repository-name distro-sync

Do not permanently remove a vendor repository until you know which installed packages depend on it.

Fedora Silverblue, Kinoite and Other Image-Based Systems

Do not use traditional DNF repair instructions as though the host were a standard Fedora Workstation installation.

Image-based Fedora systems use rpm-ostree for operating-system packages. Fedora distinguishes traditional DNF-managed systems from image-based variants.

Useful inspection commands may include:

rpm-ostree status

and:

rpm-ostree upgrade

Layered-package conflicts may require resetting, removing or replacing an override.

Use the documentation for the exact Fedora variant rather than manually altering the RPM database.

Arch Linux Repairs

Avoid Partial Upgrades

Arch Linux supports full system upgrades.

The correct normal update command is:

sudo pacman -Syu

Do not run:

sudo pacman -Sy package-name

Refreshing the repository database without upgrading the full system can install a new package against older libraries and create a partial-upgrade state. Arch explicitly warns that partial upgrades are unsupported.

Complete a Full Upgrade

When dependencies break after a partial update:

sudo pacman -Syu

Arch’s troubleshooting guidance recommends updating the whole system when a partial upgrade has occurred.

Read any news items on the Arch website before upgrading, particularly if the system has not been updated for a long time.

Refresh Mirrors When Packages Are Inconsistent

An out-of-date mirror can serve repository databases or package files that do not match.

Update the mirror list using the distribution’s recommended method, then run:

sudo pacman -Syu

Arch warns that inconsistent mirrors can contribute to partial-upgrade situations where packages no longer match.

Do not repeatedly force database refreshes without completing the upgrade.

Check the Package Database

Verify installed package files:

sudo pacman -Qkk

This can produce substantial output.

To inspect a specific package:

pacman -Qi package-name

To see what requires it:

pactree -r package-name

The pactree command is provided by the pacman-contrib package on many Arch installations.

Reinstall a Package

Use:

sudo pacman -S package-name

Pacman can use the standard installation command to reinstall an installed package.

Never Force-Remove Dependencies Casually

A command such as:

sudo pacman -Rdd package-name

skips dependency checks.

Arch warns that removing a package required by others without removing the dependants can break the system.

Use ordinary removal:

sudo pacman -R package-name

or carefully inspect the dependant packages first.

AUR Packages Can Need Rebuilding

Packages from the Arch User Repository are not official binary repository packages.

After major library updates, locally built AUR applications may require rebuilding against the new library versions.

Check whether the broken package is foreign:

pacman -Qm

Then rebuild it using your normal trusted AUR workflow.

Do not solve a missing shared library by manually creating a symbolic link to a different library version. Arch specifically warns against hiding partial-upgrade problems with manual symlinks.

openSUSE Repairs

Refresh the Repositories

Run:

sudo zypper refresh

Then update through the method appropriate to your openSUSE edition.

For Leap:

sudo zypper update

For Tumbleweed, the expected full distribution update is normally:

sudo zypper dup

Do not mix Leap and Tumbleweed repositories.

Verify Dependencies

Run:

sudo zypper verify

openSUSE documents zypper verify as the command for checking whether package dependencies are fulfilled and repairing missing requirements.

Review the proposed solution before accepting it.

Inspect Repository Priorities

List repositories:

zypper repos

Include priorities:

zypper repos -p

Conflicts can occur when packages are split between:

Official repositories
Packman
Vendor repositories
Old release repositories
Disabled repositories

Do not switch vendors globally unless that is the intended maintenance strategy.

Reinstall a Package

Use:

sudo zypper install --force package-name

This forces reinstallation of the selected package.

Remove Unneeded Dependencies Carefully

openSUSE supports removing a package and its now-unused dependencies with:

sudo zypper remove --clean-deps package-name

The documentation warns that package removal must account for the dependency tree.

Review the list before confirming.

Problems Common to Every Distribution

Mixing Distribution Releases

Dependency failures frequently occur when repository entries refer to different releases.

Examples include:

Ubuntu stable plus a future development release
Debian stable plus testing
Fedora repositories from different versions
openSUSE Leap packages mixed with Tumbleweed
Arch packages installed without a full system upgrade

Package names may look identical while requiring different library versions.

Use one supported release and repositories built for that release.

Installing Packages for the Wrong Architecture

A package may be built for:

x86_64 or amd64
ARM64 or aarch64
32-bit x86
Another architecture

Check the system:

uname -m

Common results include:

x86_64

aarch64

Do not install an ARM package on an Intel or AMD PC, or vice versa.

Multiarch setups can legitimately contain more than one architecture, but they require deliberate configuration.

Interrupted Upgrades

A power failure, forced restart or lost network connection can leave packages:

Downloaded but not installed
Unpacked but not configured
Upgraded while related packages remain old
Missing post-installation scripts

Resume the package manager before attempting unrelated installations.

Package Database Locks

Errors may mention another process holding a lock.

Before deleting any lock file, check whether an update is genuinely running:

Graphical software centres and automatic update services may be using the database.

Deleting a lock while another package process is active can corrupt package state.

Restart first if you are uncertain.

Broken Repository Signing

Repository metadata is cryptographically signed.

Signature errors can be caused by:

Incorrect system time
An expired repository key
A repository that changed its key
A failed download
An unofficial source
A man-in-the-middle or proxy problem

Do not bypass signature checking to make the update continue.

Correct the time, repository entry or signing-key setup using the repository provider’s official instructions.

Manually Downloaded Libraries

Do not search the internet for an individual .so library and copy it into:

/usr/lib

or:

/lib

The file may be:

The wrong version
Compiled for another distribution
Built for another architecture
Malicious
Missing related files
Incompatible with the system’s package database

Install the library through the distribution’s package manager.

Avoid Random Symbolic Links

A program may report:

libexample.so.4: cannot open shared object file

Creating a link from libexample.so.3 to libexample.so.4 does not make the libraries compatible.

The version number may represent a changed binary interface. The application can crash or corrupt data even if it starts.

Install or rebuild the application against the correct library.

Flatpak, Snap and AppImage Are Different

An application packaged as Flatpak, Snap or AppImage may not use the distribution’s normal dependency system in the same way.

Flatpak

Check installed applications:

flatpak list

Repair installed Flatpak objects:

flatpak repair

Update:

flatpak update

Snap

List packages:

snap list

Refresh:

sudo snap refresh

AppImage

AppImages are self-contained files, but they may still rely on certain kernel features or compatibility libraries.

Do not use APT, DNF or Pacman commands to repair a problem that exists only inside a Flatpak, Snap or AppImage package.

Python, Node and Language Dependencies

Errors from:

pip

npm

cargo

gem

are not necessarily system package-manager failures.

Avoid installing language packages globally with sudo unless the project documentation explicitly requires it.

Prefer:

Python virtual environments
Node project-local dependencies
Containers
Distribution packages
Supported language-version managers

Mixing sudo pip packages with distribution-managed Python files can create difficult conflicts.

Check the Logs

Package managers keep useful records.

Debian and Ubuntu

/var/log/apt/history.log

/var/log/apt/term.log

/var/log/dpkg.log

Fedora

/var/log/dnf.log

You can also review DNF history:

dnf history

Arch

/var/log/pacman.log

openSUSE

Zypper history is commonly recorded under:

/var/log/zypp/history

Look for the last successful change before the failure.

Undoing a Recent Package Transaction

Some package managers record transactions that can help identify what changed.

For Fedora:

dnf history

Then inspect a transaction:

dnf history info ID

Transaction rollback may be possible in some cases, but it should not be treated as a guaranteed system snapshot.

For systems where package changes are critical, file-system snapshots through tools such as Btrfs snapshots can provide a stronger recovery path when configured before the failure.

When the Graphical Software Centre Is Broken

The graphical software application may simply be displaying an error from the underlying package manager.

Close it and run the appropriate Terminal repair command.

For Ubuntu-based systems:

sudo apt update

sudo dpkg --configure -a

sudo apt --fix-broken install

For Fedora:

sudo dnf upgrade --refresh

sudo dnf distro-sync

For openSUSE:

sudo zypper refresh

sudo zypper verify

For Arch:

sudo pacman -Syu

The command-line output usually provides more useful detail.

When the Package Manager Itself Is Broken

If commands such as apt, dnf, pacman or zypper no longer run because of missing libraries, ordinary repair becomes more difficult.

Possible recovery methods include:

Booting a live USB
Entering the installed system with chroot
Reinstalling package-manager packages from a trusted cache
Restoring a snapshot
Using rescue mode
Reinstalling the operating system while preserving data

This is an advanced repair.

Do not download a replacement package manager from an unrelated distribution.

When to Restore a Snapshot

Restoring a snapshot may be safer than manually untangling hundreds of packages when:

A major distribution upgrade failed
A partial upgrade changed core libraries
The desktop no longer starts
The package manager itself is broken
A third-party repository replaced many system packages
The problem began immediately after one recorded update

Confirm that important files created after the snapshot are backed up before rolling back.

When Reinstallation Is More Sensible

Consider reinstalling when:

The system mixes several incompatible releases
Core packages were force-removed
Package databases are severely corrupted
The repair would require replacing many fundamental libraries manually
The installation is unsupported and cannot upgrade cleanly
The same dependency failures return after repairs
A clean supported system would take less time to rebuild

Protect:

Home folders
SSH keys
Browser profiles
Application data
Server configurations
Encryption keys
Package lists
Database backups

before reinstalling.

A Safe Repair Order

Use this sequence:

Record the complete error.
Identify the distribution and package manager.
Check disk space.
Restart the computer.
Confirm no package process is still running.
Refresh official repository metadata.
Complete any interrupted package configuration.
Run the package manager’s dependency repair.
Perform a full supported system update.
Inspect held, duplicate or incompatible packages.
Disable recently added third-party repositories.
Reinstall the affected package.
Remove only the confirmed incompatible package.
Check logs and transaction history.
Rebuild manually installed or community packages.
Restore a snapshot if core packages remain inconsistent.
Reinstall only after important data is protected.

Quick Commands by Distribution

Ubuntu, Debian and Mint

sudo apt update

sudo dpkg --configure -a

sudo apt --fix-broken install

sudo apt upgrade

Fedora

sudo dnf upgrade --refresh

sudo dnf distro-sync

sudo dnf repoquery --unsatisfied

Arch Linux

sudo pacman -Syu

openSUSE

sudo zypper refresh

sudo zypper verify

Run only the commands for your own distribution.

Need Help Repairing Linux Packages?

Broken dependencies may be caused by an interrupted upgrade, conflicting repositories, incompatible third-party software or a partial system update. Force-removing libraries or copying files manually can leave the entire Linux installation unstable.

Hamilton Group can diagnose package-manager errors, repair repository configuration, restore interrupted upgrades and recover affected Linux systems without unnecessarily wiping the computer.

Call 0330 043 0069 or visit hgmssp.com to speak with one of our IT experts.

Previous Next