Tag: package dependencies

Error “cannot resolve dependency lib32 (32-bit library)” (SOLVED)

When installing a package on Arch Linux or a distro derived from it, for example, by running the following command:

sudo pacman -S trid

an error may occur stating that dependencies could not be resolved. The name of this dependency can contain the number “32” or the string “lib32”, that is, it is a 32-bit package, for example:

resolving dependencies...
warning: cannot resolve "lib32-ncurses", a dependency of "trid"
:: The following package cannot be upgraded due to unresolvable dependencies:

:: Do you want to skip the above package for this upgrade? [y/N]

To fix this error, multilib must be enabled.

The multilib repository is the official repository that allows the user to run and build 32-bit applications on 64-bit Arch Linux.

To enable multilib, open the text file /etc/pacman.conf:

sudo gedit /etc/pacman.conf

Find and uncomment the lines in it (make sure to uncomment both lines, otherwise the changes will not take effect):

Include = /etc/pacman.d/mirrorlist

Update package information:

sudo pacman -Sy

And re-run the package installer – this time all dependencies should be resolved.

How to simulate package installation on Linux (How to create and install a dummy package)

Sometimes, when installing packages from source code, you may encounter the problem that the required dependency is missing from the system. Usually you need to solve this problem by installing the necessary dependencies from the standard repository, or by compiling them from source.

Sometimes the required package is present, but its version is not suitable, a similar example and solution is described in the article “How to install a package for which there is no dependency of the required version”.

But I ran into a situation where the required dependency is:

a) does not exist at all (the package was removed from the package repository)

b) functionality has been moved to another package that can be installed

Take a look at the following message:

Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 detectiteasy : Depends: qt5-default but it is not installable
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

The program installed from source requires the qt5-default package. This package contains one single configuration file. The package itself was removed as unnecessary or due to the fact that its functionality was transferred to the qtchooser package that I installed. That is, from a practical point of view, the dependency is not needed, but I cannot update the system, because, as the package manager thinks, the dependencies are broken.

The way out of this situation is to install a dummy package.

How to create and install a dummy package on Linux (Debian, Linux Mint, Kali Linux, Ubuntu)

There is a Debian package called equivs that can create fake packages. Install it by running

sudo apt install -y equivs

Due to unresolved dependencies, I was unable to install the equivs package on the problematic OS – I used another computer to help.

After installation, you create a “control” template file using the following command:

equivs-control FILE_NAME

For example:

equivs-control qt5-default

Alternative package name can be used like postfix-custom for postfix or something else.

Let's open the generated file for editing:

gedit qt5-default

An example of the content in my case:

### Commented entries have reasonable defaults.
### Uncomment to edit them.
# Source: <source package name; defaults to package name>
Section: misc
Priority: optional
# Homepage: <enter URL here; no default>
Standards-Version: 3.9.2

Package: <package name; defaults to equivs-dummy>
# Version: <enter version here; defaults to 1.0>
# Maintainer: Your Name <yourname@example.com>
# Pre-Depends: <comma-separated list of packages>
# Depends: <comma-separated list of packages>
# Recommends: <comma-separated list of packages>
# Suggests: <comma-separated list of packages>
# Provides: <comma-separated list of packages>
# Replaces: <comma-separated list of packages>
# Architecture: all
# Multi-Arch: <one of: foreign|same|allowed>
# Copyright: <copyright file; defaults to GPL2>
# Changelog: <changelog file; defaults to a generic changelog>
# Readme: <README.Debian file; defaults to a generic one>
# Extra-Files: <comma-separated list of additional files for the doc directory>
# Links: <pair of space-separated paths; First is path symlink points at, second is filename of link>
# Files: <pair of space-separated paths; First is file to include, second is destination>
#  <more pairs, if there's more than one file to include. Notice the starting space>
Description: <short description; defaults to some wise words> 
 long description and info
 second paragraph

The lines with comments indicate which defaults will be applied when creating the package – you can delete these lines or uncomment and specify your own value.

Also in the line “Package” enter the name of the package, I got it like this:

Section: misc
Priority: optional
Standards-Version: 5.15.2+dfsg-7
Version: 5.15.2
Package: qt5-default

The “Provides” line indicates that my package provides the capabilities offered by another package that one is trying to spoof.

Finally, after generating the template control file, use the equivs-build command to create a fake package like


In my case, this is:

equivs-build qt5-default

It will take a few seconds to build the package and then you can run

sudo dpkg -i PACKAGE_NAME*.deb

For example, in my case, after transferring the package to the problem system, the command is as follows:

sudo dpkg -i qt5-default_5.15.2_all.deb

After installing the package, the work of the package manager returned to normal – it is again possible to install and remove packages, update the system.

For advanced users, if your template control file has the “Requires” line, you can create metapackages to install a group of programs.

See also:

How to completely uninstall a package along with dependencies on Arch Linux (as well as BlackArch and Manjaro)

This tutorial uses pacman as the package management (uninstallation) program, but you can also use pikaur or yay instead, since the options discussed are the same for all these package managers.

Related: Automatic installation and update of AUR packages

A typical command to uninstall a program that will remove all package files:

sudo pacman -R PACKAGE

Indeed it will remove the specified package, but the configuration files of the package will remain, which will be renamed - the .pacsave extension has been added, and the dependencies that were installed for this package will remain.

To completely remove the program along with all its dependencies and without saving the configuration files, use a command like this:

sudo pacman -Rscun PACKAGE

This command uses the following options:

-c, --cascade

Remove all target packages, as well as all packages that depend on one or more target packages. This operation is recursive and must be used with caution as it can remove many potentially needed packages.

-n, --nosave

Instructs pacman to ignore backup configuration files. Usually, when a package is removed from the system, the database checks whether the configuration file should be renamed (the .pacsave extension is appended to it). When using this option, this does not happen - the configuration files are completely deleted.

-s, --recursive

Removes every specified target, including all its dependencies, provided that: (A) they are not required by other packages; and (B) they were not explicitly installed by the user. This operation is recursive and similar to the reverse --sync operation, and it helps to keep the system clean without orphans. If you want to skip condition (B), write the option twice.

-u, --unneeded

Removes targets that are not required by other packages. This is mostly useful when removing a group without using the -c option to avoid breaking any dependencies.