[SOLVED] A "software repo/package manager" sticky?

Fair call RT.

While I'll see what I can do; a couple of concerns I would have would be for one, it has to flow, so the previous section flows into the next one, and it's therefore easy to follow. Also, it really depends on how advanced the situation is, so for example, depending on this, and if it's too advanced, the only viable solution maybe to do a complete reinstall, it maybe the "safest" option in that particular case too. So while I think a better description of the intended purpose of the sticky is very doable, and the steps to determine if the OP is facing this particular problem is doable; what they should do if let's say they are facing this situation the sticky is intended to help with, really depends on how far advanced their problems are. It would also depend to at least some extent on both their Linux distribution, as well as the repo's involved.

So I think the "steps" would also have to be general in nature, rather than aimed at a particular distro or package manager.

I'll do the best I can with what you've suggested in any case tho. But I think this is going to delay posting a revised final draft (RFC 3) tho.

Originally Posted by jsbjsb001 So I think the "steps" would also have to be general in nature, rather than aimed at a particular distro or package manager.

Not disagreeing that they may not be exactly this, something general. Meanwhile you'll probably have two or more flows of steps.

1. With a clear definition, they'll understand whether or not the post addresses their category of problem.
2. With some clear guidance, they can learn more specifics of their problem.
3. At that point, you can advise for the feint of heart/experience that they may choose to either:
   1. Ask an LQ question with sufficient background information they now have.
   2. Do something drastic to reset their situation.
4. Or instead you may now give more detailed directions in multiple paths, depending upon the varieties of paths an advanced user may follow to attempt to resolve their problem.

Originally Posted by jsbjsb001 I'll do the best I can with what you've suggested in any case tho. But I think this is going to delay posting a revised final draft (RFC 3) tho.

Better to be on the mark versus timely.

Thanks RT.

I've rearranged the existing sections and added a couple of new ones dealing with how to learn more about the nature of the problem, and some general advice on what to do next. I think in terms of "what to do" once they have learnt more about the nature of their problem; it's better just to give some general advice, with a line saying something to the effect of "if you're still unsure what to do next, then it maybe time to post a question. Please refer to the "What information should I include when posting a question about software package problems?" section below for information required, so LQ members can advise on further action to take". Rather than offering multiple "options" on action to take - to make it easier for people who don't have much experience with Linux/package managers, and/or "newbies". I figure that it's likely if they still are unsure at that point, they'll probably need some support from more knowledgeable people here anyway. And in that case, it's likely they are indeed a "newbie" anyway - so better to "ask the experts" so to speak. Rather than make even more of a mess of their system.

I have got a revised draft ready now, but I agree with you that it's better to try and make sure it's on the mark, and a "newbie" can at least have enough info to determine the nature of their problem (whether they can fix it by themselves or not). So I'll delay posting a revised draft for now, and I'll have another look at what I've got so far tomorrow/later on today, as it's night time here now, and I've gotta get some sleep.

Preamble

The purpose of this sticky is to guide users on diagnosing problems with installing, upgrading and/or removing software packages using package managers. This sticky thread is intended to cover problems that arise with software repositories causing problems with the installation, or updating of software packages. It does not cover all possible issues that could arise with package managers and/or software packages.

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 sticky post 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 sticky thread.

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.

How to determine if you are facing a problem with enabled software repositories

• Examine any error messages from your package manager, as this will often give you some clues as to the nature of the problem you're facing. If it's mentioning the same package(s) name(s), but different versions in different software repositories you have enabled; then you likely a conflict. Therefore, your package manager is likely having problems resolving the package dependencies.
  *
• Ensure that any third party software repositories 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 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.
  *
• 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.

I believe I have a problem related to enabled software repositories, what do I do?

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 install".

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 the "What information should I include when posting a question about software package problems?" section 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 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>

Replace <name of package manager/frontend here> with the actual name of your package manager/frontend, such as apt, apt-get, yum, dnf, etc.

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;

inxi -r

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 shared libraries, and other software needs to also be installed. If a program uses 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 optimisations 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 post.

More Resources:

• 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
• Basics Of Compiling Software From Source Code In Linux
• Compile Software From Source Code

1st paragraph:
...then you probably have a conflict and your package manager is unable to resolve the package dependencies.

Not to be a pill, but I feel it is nearly the same document.

I fully understand if there are no opinions along my same line of thinking.

I less see the need for a disclaimer, than instead a very clear set ot statements indicating: who the target audience is, what problem it is intended to help along with an indication of what type of install problems it is not helpful for, and finally a process to follow to determine that you do have a situation which this addresses.

Not saying a lot of that isn't somewhat there, however right now it reads very much like:

"Legal disclaimer, ad infinitum.", followed by a ton of detailed technical information.

Near the bottom it talks about how to diagnose things.

I personally stop reading at some legal disclaimer and conclude that I have no idea whether or not this document would be helpful to me.

Maybe things are different from where you are, but I do not use the term Preamble. I use Introduction.

Some additional thoughts.

You are writing a lengthy document intended to convey a complex message, however one that is highly specific to a certain audience.

I've written volumes of documents like this. Technical specs, quotes, requests for quotes, requirement documents, technical designs, product documentation. I would say that a very large percentage of these documents sometimes see a lot of changes.

One puts in a great deal of time and effort to create something. It represents their line of thinking, and they are so very much inside this document that they fully understand all which it says. They follow the logic as if it is 100% natural to them.

Changes occur if the client decides their project goals or scope have changed, or if their budget is different than they originally thought. Meanwhile there are several audiences, such as your management, your client, client leaders including financial backers, and attorneys.

I've found that I've rewritten, and eventually reorganized the same document ... call it, "23 ways to Sunday".

This truly does tax ones' patience. You get frustrated and you sometimes can't understand why another reader doesn't get your point.

But it is important that they do understand the point of the document, because in the cases I'm talking about, it means an approval of funding, a purchase order being granted, or a contract being agreed upon.

There are several tactics.

Let another person entirely write the document. I say "let", but sometimes you're the employee and your management decides to take it upon their selves, and so they do it. Turns out it is a completely different document (sometimes), which still captures a lot of the details which you originally had. Your reactions may vary from "That's what I said!!", to "Oh ... didn't think that they considered that direction to be important or viable ...".

Another tactic is to step back and force organization upon yourself. Like when you write a term paper in school, you are required to provide a thesis statement for it and an overview and then typically you are required to turn in an outline of your intended document. We all hated it during school, (maybe), but if you end up needing to write complicated documents as part of your job, you actually benefit from some of those lessons.

Another tactic might be to just take a large step back and do a similar exercise as you would with a school paper assignment, you reinvent your whole document from the ground up, concentrating on a different perspective and also viewing it from several perspectives. And you determine if the content really says something which is helpful. This option is one typical for me in cases where I do not feel I've conveyed my messages correctly as yet. Why? Well for starters, I'm very much inside the topic, so it's never some total effort from the ground up. The writing may be, but the ideas and the background are all there already. I have to force myself to view it from the non-experienced persons' viewpoint.

To be entirely clear with my opinions:
1. I'm not sure "how" exactly this document helps the user who has messed up repositories.
2. It contains a great deal of detailed technical information. Too much in my opinion.

Final thought process:
The two of us are working together.
Something's messed up on my system and I can't install an editor. I'm very competent, you and I both know this, we work together.
I complain, you look over, you make some suggestions. You decide it's also a curiosity.
You ask me a bunch of quick questions and based on your experience, you conclude this is the exact problem category you're talking about here.

But say I'm still not getting it, and this frustrates you.
How do you break through there? In your frustration do you say, "Look ... type BLAH-BLAH! HIT ENTER!!! DO IT!!!!! DON'T ARGUE ... DO IT!!!"
And eventually I do, and you scream, "SEE!!!!! THAT'S WHAT I'M TALKING ABOUT! THAT'S WRONG! IT NEEDS FIXING!"
I finally go ... "Ohh...grumble a bit, and then ask what do I do about it", and then you proceed to tell me how to fix it.
Maybe afterward I say, "Yeah ... I get it, but how did I get there?"
After that we can discuss Linux and package development ad nausea forever and ever until we get too frustrated to talk about it. But until that point, if I'm not understanding the definition of the problem with my own system, any detailed conversation is entirely moot.

Set all the details aside.
Help the person who needs help, but doesn't understand that they do, or why.

I can change what Hazel's suggested, along with some other fairly minor changes, which should be easy enough.

I did try and add those two new sub-sections with the following thoughts in mind, and let's say someone posts a question about the problem proposed sticky is dealing with;

* What would I be looking for to confirm it is a problem with software repositories?
* How would I come to that view?
* How would I ask them to do the relevant checks to confirm, in a way that's understandable to them (when dealing with someone with no experience)?
* How would I explain their problem to them (once it's been confirmed)?
* How would I suggest the solution to them?

I also tried to write it with the "less is more" approach in mind, so that it's gives them the detail they would need to understand the problem; but not try and overwhelm them with the details. It's also the reason I moved the "Common package manager issues" section up to the top, and added the new sub-sections under it. I also think I did make it clear in the "Preamble" section what the sticky is supposed to help with, and there is more detailed general info about package managers below those sections. Therefore if they want to read it, they can, but they can still just read the first sections instead if they want.

I think as long as it's to the point, is understandable, and relevant, then I think someone who's committed to trying to solve their problem would; be able to see what they need to "check" to work out the exact nature of their problem, and work out if the sticky is likely to help them/is relevant to their problem. As I remember when I started out looking for answers, and even sometimes now if I don't understand something; I'll see if it makes any sense to me, and let's say what I'm reading does; the next question for me would be; is this info relevant to my problem? Let's say it is; great, but do I understand what it's saying and/or what the "proposed solution" is? If the answer is still yes, and it solves/helps me solve my problem(s), then that info was indeed helpful in that example. I don't pay attention to the exact wording, as long as it's understandable, and I truly CAN understand the point(s) it's making.

The bottom line: while again, some fairly minor changes can certainly be made; I'm not sure how to change it beyond that and what I already have, without either making it less understandable, leaving out relevant details, and/or completely overwhelming them with too many details. I'm also not sure how I can make it's intent or content much clearer beyond some fairly minor changes here and there.

If you've got any specific paragraph(s) you think should be changed, and exactly what you think it/they should be changed to RT, you're more than welcome to post that. But I'm once again not really sure exactly how I could get it exactly where you think it should be - I'm not being a smartass or anything, but I'm honestly starting to be at a loss there.

Title: Common Problems Installing Linux Software Packages

Introduction

You've been pointed to this sticky to help aid you with a problem installing Linux software.

Target Audience: Who This Sticky Is For, And Who It Is Not For

1. Those who are very new, or non-familiar with Linux who are trying to install software and merely do not know the best means to install Linux software.
   This sticky is not intended to help your situation.
   
   In this first case, this is where you can go to look for overviews of the process to install Linux software packages:

   fake-reference-1.html
   fake-reference-2.html

2. Those who are trying to install Linux software and have found there to be problems in spite of a normal installation attempt.
   If this is your situation, this sticky may provide some assistance to diagnose your problem.

Discussion

As stated in the Target Audience section, this sticky is intended to help those who already know how to install Linux software, but have run into problems that they do not understand, or cannot diagnose and fix.

What are some common package manager problems that you can encounter?

1. Corrupted repositories
2. Dependency issues
3. ?? <one phrase descriptions here - this is you and your expertise>

How do you know that you have one of these problems? What can you do to diagnose one over the other?

Option 1: Issue the command

$ inxi -r

Option 2: If inxi is not available on your system, an alternative is:

tell them what to do

Next Sticky Steps

1. Tell them how to interpret what they just read. And if everything is fine, tell them that and tell them to stop reading and thus learn how to install software properly.
2. Tell them if they don't understand, how to formulate a question, where to place it, what approximately to title it, and what information to include with the question. Tell them, do not post a link to anything.
3. Go on with all your detailed stuff - or consider what parts of it may not be so very relevant.

Based on my amateurish viewpoint of the contents of this sticky, this is about what I think it should say, and how it should flow.

The suggested title certainly sounds good. I still hadn't really decided on any particular title, but assuming the sticky gets the green light, and no-one else can think of a better title; I could certainly see myself using either that title, or a very similar one.

As far as "Preamble vs Introduction" is concerned; I honestly can't see how it's a big deal which particular word is used. "Preamble" does in fact mean "Introduction" anyway, and as I was saying before; I very much doubt someone looking for a possible solution to their problem is going to care about which of those words are used - provided once again they can understand and follow the suggested actions to determine if they have a problem the sticky deals with, and what the possible solution(s) is/are. Also, it's not just people that may be pointed to it, that might decide to read it - as others who haven't been pointed to it might decide to read it (and likely will). So having a line saying something like "you have been pointed to this sticky to/because..." could mislead people/could be misleading. So I don't honestly think that's a good idea to have such a line anywhere in it.

While I agree that the "target audience" could be more clearly defined; I think for one thing, that can be done in the existing "Preamble" section - I don't think adding any new section is necessary for that. Also, I don't think it's wise to be adding further possible problems to the sticky, and it therefore should just focus on the most common issues, which from posts here seem to be; a) they have enabled an incorrect version of said repo(s) for a distro their not intended for, eg. repo's meant for CentOS 7 being enabled on CentOS 6. b) adding incompatible third party repo's.

I also don't think it's wise to have another "procedure" if they don't have inxi installed. As once again, and as already stated in the draft; there are many different package managers out there, so there is no single answer as to how to get a list of enabled repo's. Again, if we list "steps" for every package manager currently available, then if a new one comes along, it may lead the reader (particularly "newbies") to think that for one, the sticky doesn't apply to them, even if they ARE having a problem it deals with.

Don't get me wrong RT; I DO understand your points, and I don't honestly disagree with you generally speaking, and do understand why you say what you say. But I really do think that the sticky needs to be general while providing the necessary and relevant info. At the end of the day, while it is meant to help people figure out what kind of problem they're having and also what some possible solutions could be; it's not meant to replace their own thinking. It's not meant to "hold their hand", or indeed prevent them asking a question if they cannot fix it without help. It's meant to give them at least enough info to be able to provide in the event they DO need some help with it here, if nothing else. Obviously all the better if they manage to solve it without having to ask a question. But the idea isn't to necessarily stop them from seeking help for their problem here. So I'm not sure it's wise to have "procedures" as such in it.

I disagree and feel you need to show a clear process to people, and explain the exceptions to the various steps.

What do you tell someone who is trying to install from source? A: view README, as well as: configure, make, sudo make install.
If they reply that they couldn't run make, what do you tell them to check? A: that they have tools installed, and you tell them how to check this and how to fix it.

What do you tell someone who is trying to install a binary Linux distribution? A: determine what they wish the target to be like (wipe out or dual boot), and confirm that understand how to make the boot/install media.

While I do understand what you're saying, and do agree in "principle" with you; I think what I've already added more or less does list a "process", and to at least some extent the "expectations". The problem is that this sticky isn't meant to be specific to just one package manager, or just one particular problem - although it's dealing with one category of problems.

So while it would be much easier to do what you suggest if it did only deal with one type of problem, rather than one of category of problems, and particularly, only one package manager; it doesn't just refer to only one package manager nor just one particular problem. So while we maybe able to get something close to what you've suggested, given the above; I don't think it will be able to be exactly what you're thinking it should be RT.

I'll do the best I can, and I've added a few things to it tonight, but it still can't be specific to a particular package manager. Because that's not going to be helpful to someone using a different package manager. As one example: yum has a command being the "repolist" command to display enabled software repo's, but I'm not aware of anything similar for apt - but certainly not limited to that example. So this is the problem we have.

EDIT: Also, I'm not sure making it a "how-to" like sticky is a good idea. As the idea was to provide enough info for the reader to be able to know what to look for, and do their own troubleshooting. Rather than do the thinking for them, and if they once again can't solve it themselves, they at least know what info to provide.

Originally Posted by jsbjsb001 I was wondering if a sticky about common package manager problems might help, since threads regarding problems caused by adding incorrect software repo's and alike, seem to crop up on regular basis. I was thinking that it could be used by both people having such problems, and well as members that are trying to help. Because it could include both some tips for OP's to help them solve their problem without having to ask the question, or if their still stuck, it could at least give the OP some ideas on both what they can try, and what info to provide in the event they cannot solve the problem by themselves.

From this description it seems the intent was to be a guide.

Any example threads where the latest draft would help, as well as exactly which content in the draft would actually provide the help?

Originally Posted by rtmistler From this description it seems the intent was to be a guide.

Perhaps my OP wasn't the best wording to use, although it does IMO pretty much state the intent behind it. I think, and no disrespect, you have the wrong impression of both the people that may read it, as well as the main purposes of it. It isn't just meant to be there so members can point people to it - as whether some members believe it or not, some people DO read stickies. It isn't just meant for "newbies" having problems due to incompatible repo's, it isn't just meant for people that do know how to install software packages in Linux. It's also meant to help, and hopefully save members responding some time. It's not necessarily meant to provide a "hard and fast procedure"/a "how-to" as such, and this would be very difficult for the reasons already stated earlier on in this thread.

As an example: someone posts a question who DOES know how to install packages, but has enabled incompatible repo's causing their package manager to bulk at them. They read the sticky beforehand; they based on that, think "well, I do have some third party repo's enabled, perhaps this is my problem". But they are not sure about what to look for to determine if that is their problem (or similar). Then they post a question because of that; a member who responds can also use the sticky to get a "sense" of the possible nature of the OP's problem. They and/or the OP get an idea of what some potential solutions are, to solve the OP's problem. They work with the OP based on what they've read in the sticky, they confirm it is in fact a problem with enabled software repo's. They then figure out a solution that works and solves the problem.

I'm not really sure what else I can say other than that about it's intent.

Any example threads where the latest draft would help, as well as exactly which content in the draft would actually provide the help?

I think a number of the sections could very well help, particularly the "Common package manager issues" section, along with the ones I've added. As well as at least some of the others - that's why I wrote them.

While I can think of several threads that both I've responded to, as well as others have responded to, including the one Frank refers to earlier on in this thread; I don't have any links on hand at the moment. As I haven't got time at the minute to try and dig them up for you. That said, I think if you done the right search, it shouldn't be too hard to find threads where people have had incorrect/incompatible repo's enabled that prevented them from being able to update and/or install packages.

While I'll try my best to once again do as much as I can of what you've suggested; I think it's going to be a "closest I can get case", in that, because you seem to have the wrong impressions about it; I still don't think I can completely do what you've suggested. If anyone can think of a way to satisfy all concerns, then you're welcome to post it here.

I'll put together another draft later on this week or next week sometime.

Preamble

The purpose of this sticky is to guide users on diagnosing problems with installing, upgrading and/or removing software packages using package managers. This sticky thread 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 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 sticky regarding such matters. It also does not cover all possible issues that could arise with package managers and/or software packages.

This sticky 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 sticky post 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 sticky thread.

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 post for further information.

I believe I have a problem related to enabled software repositories, what do I do?

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 the "What information should I include when posting a question about software package problems?" section 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 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>

Replace <name of package manager/frontend here> with the actual name of your package manager/frontend, such as apt, apt-get, yum, dnf, etc.

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;

inxi -r

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 shared libraries, and other software needs to also be installed. If a program uses 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 optimisations 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 post.

More Resources:

• 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
• Basics Of Compiling Software From Source Code In Linux
• Compile Software From Source Code