Software Repo / Package Manager FAQ
- 1 Preamble
- 2 Common package manager issues
- 2.1 How to determine if you are facing a problem with enabled software repositories
- 2.2 I believe I have a problem related to enabled software repositories, what do I do?
- 2.3 What information should I include when posting a question about software package problems?
- 2.4 How can I get a list of software repositories enabled on my system?
- 3 Why packages managers and software packages?
- 4 Installing software via package manager's vs from sources
- 5 More Resources
The purpose of this wiki article is to guide users on diagnosing problems with installing, upgrading and/or removing software packages using package managers. This wiki article is intended to cover problems that arise with software repositories causing problems with the installation, or updating of software packages. It is not intended to guide readers on merely installing, updating, or removing Linux software from Linux systems, be that through software packages, or via other means. There is some resources in the "More Resources" section at the end of this wiki article regarding such matters. It also does not cover all possible issues that could arise with package managers and/or software packages.
This wiki article is not intended to be a "how-to" guide as such, nor is it intended to replace your own troubleshooting; it is intended to provide some ideas on how you might troubleshoot problems involving software repositories, as well as some ideas and tips on some common causes of such problems, as well as some possible solutions to those problems.
There is also some general background on packages managers below the next section. This explains some fundamentals that should be understood when dealing with package managers – particularly when trying to solve problems related to package managers and/or software packages.
Note: This wiki article is by no means a complete guide to package managers, software packages, or software repositories; more information can be found in the "More Resources" section at the end of this wiki article.
Common package manager issues
Some common problems with installing/updating software packages, stem from incompatible software repositories being enabled. This may be a repository meant for a different version of the Linux distribution you're using (or a different Linux distribution entirely) - such as having repositories for CentOS 7 enabled on CentOS 6, for example.
Probably a more common problem would be "third party software repositories" that have different versions of shared libraries that are also included in your Linux distribution's official software repositories. This can cause major problems, and can very easily lead to something known as "dependency hell". This means your package manager cannot satisfy the dependencies for the package(s) you're trying to install, without breaking the dependencies for packages that are already installed - thus you cannot install or update the packages you're trying to install or update. Therefore the package manager is unable to "resolve the dependencies". This is more likely than not caused by having repositories enabled that have the same packages, but different versions of those same packages - this will lead to confusion for your package manager. This will very likely cancel out the installation/update, and therefore your package manager cannot proceed with the installation and/or update.
How to determine if you are facing a problem with enabled software repositories
The first step is to examine any error messages from your package manager. This will often give you some clues as to the nature of the problem you're facing.
If you have not added any additional software repositories to your package manager's "repolist", and you're seeing messages indicating you may have conflicting software package versions, check the following points;
- If it's mentioning the same package(s) name(s), but different versions in different software repositories you have enabled; then you probably have a conflict and your package manager is having problems resolving the package dependencies.
- Check to see if the official repositories for your Linux distribution have the same packages you're having trouble with in them. If they do, then this could be causing a conflict.
If you have added any third party repositories to your package manager's "repolist", then check the following points;
- Ensure that any third party software repositorie(s) you may have enabled in your package manager, are the correct version(s) for your Linux distribution. If this is not true, then this could be the problem.
- Check if more than one enabled third party software repository(s) contains a package(s) with the same name in them, and particularly if it's mentioned in any error messages your package manager is giving you when you attempt to install or update packages that you're having problems with. If this is true, then you have a conflict on your hands.
Note: How you check the above dot points is dependant on your package manager, so there is no single answer to this question. Check the following sections, as well as the "More Resources" section at the end of this wiki article for further information.
The answer to this really depends on both your Linux distribution, as well as the software repositories involved, and particularly how far advanced the situation is.
The general solution would be to remove the offending software repositorie(s) from your package manager's "repolist". You should also consult your Linux distribution's website for a list of official repositories, to figure out which are "third party software repositories", and which ones are official repositories.
If your problems are too advanced; the "safest" and/or the most "viable" solution may be to backup any important data to external media, then do a complete reinstall of your system; therefore, starting off with a "clean installation".
If your situation is very advanced; you can try removing all but official repositories, then forcing an update of all "base packages" for your distribution, but there is no guarantee this will solve your problems.
If you are still unsure at this point, then it may be time to post a question here at LQ for further assistance with your problem. See "What information should I include when posting a question about software package problems?" below for the information LQ members will require to be able to help you solve the issue.
Note: This "repolist" may go by a different name, such as "software sources", or similar, depending on your package manager/frontend. It’s advisable to actually remove the relevant line(s) listing the offending software repositorie(s) from your package manager’s "repolist", rather than just "disabling" the offending software repositorie(s).
What information should I include when posting a question about software package problems?
The following information will help LQ members figure out what might be the reason(s) for your problems. Because without this information, we are really just guessing, and this does not help you solve your problem. Please also use CODE tags when posting terminal output, as this makes it much easier for LQ members to read, and separates comments from command output.
- The name of the package(s) you're trying to install/update/remove
- The name and version of your Linux distribution
- A listing of enabled software repositories on your system
- Any error messages from the package manager/frontend
How can I get a list of software repositories enabled on my system?
While there are graphical ways of getting this information, because there are many different package managers, different Linux distributions use different package managers, the easiest way is via the terminal. Because there are many different package managers, there is no single answer to this question. Therefore, it will depend on both your Linux distribution, as well as the package manager concerned. If your package manager has an option for this (not all of them do), the best place to look would be at the manual pages for your package manager. You can type the following into a terminal window to bring up the manual page:
man <name of package manager/frontend here>
Note: Some distributions don't install the manual pages by default, in this case, you should consult your distribution's website.
There is also a separate utility that can list the repositories in your package manager's "repolist". If you have inxi installed on your system, you can run the following command from the terminal;
It does not matter which terminal program you use, nor which shell your system uses by default.
Why packages managers and software packages?
It's worthwhile to understand why we have package managers and software packages. Package managers provide a consistent way to install, update, and remove software on/from Linux systems. This is because software packages not only contain the pre-compiled version of software, but also usually check to see what else needs to be present on your system for the software in question to work. This is known as "dependency resolution"; in other words, the package manager checks the package's metadata to see which dynamic libraries, and other software needs to also be installed. If a program uses dynamic/shared libraries that are contained in a different software package(s), then that other package(s) is said to be a "dependency". The package(s) you're trying to install/update "depend" on that other package(s) to work. The package metadata also contains information about what files are contained within the software package(s), where on the filesystem those files should be installed to, what permissions should be assigned, what scripts should be run when the package(s) are installed, what services should be started, etc. The package manager keeps this information in a database on your system, so it can keep track of what files belong to what packages, what changes are made and alike. Linux package managers/frontends are a precursor to "app stores" for smartphones and the like.
Some Linux distributions (for example Crux, Gentoo) are source-based. They download source code and build the binary package locally, often with specific optimizations for your hardware. Surprisingly, their package managers function in exactly the same way as package managers do in binary-based Linux distributions. There is a high-level frontend that downloads the package from the repository together with any other packages on which it is dependent, and a low-level package manager that unpacks the sources, builds the packages, and installs them. The main difference is that each package includes a simple script which gives the package manager the instructions for the build.
Note: It's important to understand that software packages can also contain other types of files as well; they can (and often do) contain files like configuration files, wallpapers, etc.
Package manager "frontends"
Package manager "frontends" provide functions that the package manager itself does not, for instance, dealing with software repositories. An example of a package manager "frontend" would be yum; yum can both download packages from an online or local repository, and install, update and remove packages. yum uses the rpm package manager (Redhat package manager) "behind the scenes"; the rpm package manager is the actual package manager in that example; it keeps a database of installed packages. So the rpm package manager is a "dependency" of yum, because yum calls on the rpm package manager to actually "manage" installed packages.
Third party software repositories
Third party software repositories are software repositories that are maintained by a third party and are beyond the control of your Linux distribution's developers. Therefore your Linux distribution can make no guarantee that it will not cause problems; more importantly, adding such repositories increases the possibility that you may encounter package dependency problems.
PPA’s (Personal Package Archives) are also an example of a "third party software repositories", and are even more risky. Some of the risks involved with PPA’s are security related, as well as whether or not packages contained within will continue to receive updates, particularly security updates. There is also the risk of who exactly is behind said PPA(s), and how much testing has gone into the software concerned, as well as the experience the maintainer of said PPA have.
It's advisable to keep third party repositories to an absolute minimum, and only use ones that are known to not be problematic. Your Linux distribution's website is usually a good source for such information. The bottom line is that, if you go overboard with adding third party software repositories, then you are very likely to have serious problems. This can also lead to what's known as a "frankendistro". In other words, and as an example (but not limited to), Debian stable that's not really Debian stable, but a mixture of Debian stable and Debian testing.
The best rule of thumb is to only use "third party repositories" when there are no suitable packages for the software in question in the official repositories for your Linux distribution, and to only use trusted repositories. Even then, it is safer to build the package from source if you can. That will ensure that it is linked to the library versions that your system provides.
If in doubt, don’t add it!
If you play with fire, you're likely to get burnt!
Installing software via package manager's vs from sources
Before one can use software written in a compiled programming language, it must be "converted" from human readable code (aka "source code") to machine code instructions for your computer's processor to be able to "see" it as a set of instructions to perform a specific task. So when we say something like "building it from source", this is what we mean, in other words; you would use a compiler to "compile" the source code to machine code instructions.
In binary-based Linux distributions, the developers of said distributions have already done the above for you, and put the end result into "software packages". You should therefore in this case, be able to simply tell your package manager to install the relevant package(s). This will therefore install the pre-compiled binary version of said software onto your system, and therefore you can start using said software, as at this point, it already has been "converted" into machine code instructions that your computer's processor understands to be a set of instructions.
Further information about this topic can be found in the "More Resources" section below, as further details are beyond the scope of this wiki article.
A note about managing software that has been installed from source
A problem with building software from source by hand is that the package manager then knows nothing about it because it was installed independently. Therefore the package manager cannot "manage" the updating or removal of that software. To bridge this gap, there are some extra tools such as "porg" you can install, that will record information about that software's installation in a separate database. This is not an issue in a source-based distribution which uses its package manager to download and build automatically from source.
- Package management
- Installing software
- Package Managers and how to use them
- More information about software repositories for Debian, Ubuntu and Linux Mint
- Don't break Debian
- A guide to Linux software packages - The basics remain the same, but Fedora has moved to dnf
- Additional software repositories for CentOS - A list of third party repositories available for CentOS
- How to enable and disable repositories on CentOS
- Ubuntu's apt-get how-to guide
- yum cheatsheet
- A beginners guide to yum configuration
- Create your own Debian software packages
- Creating a Debian package
- How to create your own rpm packages
- rpm packaging guide from Redhat
- Building custom rpm packages
- Source code
- Compilation from source
- Basics Of Compiling Software From Source Code In Linux
- Compile Software From Source Code