I just pointed a poster to jsbjsb001's post above with his draft sticky because it seemed to be a perfect fit to the poster's Linux Question. In this case, the poster had a repo list that included a PPA for a different version of Ubuntu than the one the Linux Questioner was running, one of the items specifically addressed in the draft above.

I submit this as Exhibit A on behalf of the proposed sticky.

1 members found this post helpful.

Preamble

The purpose of this sticky is to guide users on diagnosing problems with installing, upgrading and/or removing software packages. This sticky thread only covers a few of the most common issues, and does not cover all possible issues that could arise with package managers and/or software packages. See the “Common package manager issues“ section below for more information about common issues with software packages, and package managers. This sticky post is by no means a complete guide to package managers and software packages; more information can be found in the "More Resources" section below.

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: 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.

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.

The solution in the above examples would be to remove the offending software repositorie(s) from your package manager's "repolist".

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).

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, hence the term "third party software repository". 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.

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;

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;

It does not matter which terminal program you use, nor which shell your system uses by default.

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

You don't need "hence the name third party software repository". The rest of the sentence defines it perfectly.

Next sentence, put a semicolon after "problems", not a comma.

After the sentence beginning "The best rule of thumb...", I would add a further couple of sentences: "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." Normally I wouldn't encourage newbies to build their own software but it is still safer than downloading binaries from God knows where. That's the Windows way of doing things that we want to wean them from.

1 members found this post helpful.

Thanks Hazel.

I'll change the comma, to a semicolon like you said. The suggested content seems reasonable to me, and I hadn't even thought of adding anything like that, but again, it does seem reasonable to me. I'll have to fix some of the double quotes (I didn't purposely make some of the double quotes italic, that was LibreOffice Writer that done that), as I'd prefer normal double quotes, not italic ones.

I'll give it until the end or end-ish of the week to see if any more comments/suggestions roll in, then post RFC 3 with the suggested modifications for LQ's consideration for sticky'ing.

I'm indifferent to sticky or blog. As long as something helpful is able to be readily referenced is acceptable. As much as you point people to reference material, if they're not going to read, then they are not.

Next is whether or not the information is helpful.

There's a lot of information here, it is intended to be helpful. Who exactly is the audience? I've loaded all the links and they vary between:

1. more discussion along the same lines
2. pure instructive command examples (I personally like these best)
3. instructions about how to create packages

I am not a software repository person. I use them, mostly apt and (d/o)pkg. I've learned what works and how to use them.

One problem may be when you're trying to install something "special", and 3rd party repos come into play, or conflicting dependencies. I fully agree that staying away from 3rd party repos is smart and if given the option, to instead install from source. If it all is so very much complicated, then I choose to not install and I accept that situation, which I feel should be noted to the amateur user.

I've spent far too much time in my past trying to get something into a system that was old, complicated, or not developed well enough to install easy. That has usually led to system instability or entirely broken systems. This is why I recommend that people should be told that you can only go so far sometimes.

Another problem may be if the repos or something in the system is broken and things like "apt get update" don't work successfully. So how do you fix it? There's actually tons of references on the web about varied commands to try to auto reset/flush/clear your situation.

The target audience I'm thinking about here would be the pure amateur who is trying to install software using a package manager.

They need a brief overview of what the subject of package management is about and why there are different ones.

They need a summary of the package managers.

They need brief, typical example commands and more detailed reference links for each to give them greater details.

Regarding links. I do realize Jeremy has stated that links are troublesome because they get out of date. I have no alternatives here, but my inputs clearly are that when someone uses a link, that they expose the actual link and not use the url= BB code and then say something unhelpful about what the link is. Too many times I see people show a link (self included) that says "here", and I'm reading, thinking, "I'm not following that!", I'd assume others may feel similar, and along with this, they are also trying to read your paragraph. Inserting a link in the middle of it is counterproductive. I don't follow a lot of those because of the very fact that I'm reading someone's paragraph and I don't like to disrupt that reviewing activity by following some number of sidebars.

They need to understand what it would mean to install from source versus use a package manager, but also should be pointed to another reference and informed that this is beyond the scope of this informative post/blog.

They certainly can be told that there's a whole subject area related to building your own packages for deployment, but also should be pointed to another reference and informed that this is beyond the scope of this informative post/blog.

1 members found this post helpful.

I think that a sticky would have more visibility than a blog. I suspect that many LQers visit the blogs--er--infrequently. I know I do, even though I've made a few blog posts.

As I mentioned earlier, I don't think that the sticky by itself would attract the attention it deserves from the persons who need to read it, but posters responding to a Linux Question could point the questioner to the sticky in their responses. I've already had occasion to point a poster to jsbjsb001's first draft, as it spoke directly to the poster's problem.

I also think that rtmistler's suggestion about a similar post regarding compiling from sources has merit; I'd also say make it a sticky for reasons of visibility. I'll volunteer to write it, but it may be a couple of weeks before I have a draft because real life.

1 members found this post helpful.

I'm sorry to be a fly in the ointment but I feel that there is a danger of having too many stickies in a subforum. I personally hate it when I go on a forum and there is a long list of stickies before you get to the action. I believe that stickies should only be for very important topics that have a direct impact on a large number of users, "must reads" so to speak. Imo. I would suggest that both this and frankbell's proposed topic would therefore be better suited as blog posts. I suspect that they won't be read by users in either way unless the users are specifically pointed at them, and this can be done just as well in blog post format.

1 members found this post helpful.

At least the original idea would have been people having problems with their package manager, be that the "newbie" or otherwise. Although the "newbie" would be the most likely to have such problems and need some help.

My idea with the "More Resources" section at the end was to have useful references there that cover things beyond the intended scope of the post.

I do see what your saying, but I'm honestly not sure how to include something like that without going beyond the intended scope of the post. If anyone has any ideas on how that could be done, I'm open to any suggestions about that.

I'm not sure I entirely understand exactly what you're meaning there. Do you mean the "workflow" of say when someone install's a package? What packages are? All of the above? Could you expand on that? Because I think the danger is that the proposed sticky becomes too bloated, and could have the opposite effect - particularly for the complete "newbie".

Do you mean listing every package manager available, with examples of how to use them?

I think I can get some more detailed reference links, but giving command examples might not be easy without giving command examples for every package manager. Personally, I think it would be better to try and keep it as general as possible, and just stick to the fundamentals - for the same reasons as above.

I think that's probably a good idea, as it does make things more clear - particularly for the "newbie" who may be wondering what "building from source" means. While it's something I just quickly typed up on the fly, maybe a new sub-section like;

And if Frank wants to do a post about building from source, then the last sentence could be changed to point to his post/sticky instead, or a link to it be inserted in the "More Resources" section.

I think that's very doable, it's just a matter of which section such a sentence should be in.

While I can understand your point about a lot of stickies in the one subforum, this issue does come up quite a bit, so I would argue there's merit for having a sticky verses a blog post. I disagree that people won't read it, while maybe not everyone will, those that have questions on this topic who are looking for answers anyway likely will. Also, and as I said before, not everyone is going to read blog posts either, and some people may not even read that part of the site period. So they are more likely to see and read it, if it's sticky'd instead - it's more "visible" IMHO as a sticky, rather than a blog post. So I agree with Frank on that one. And I disagree with the idea that if it's made a sticky thread, then it won't be read, I think that's largely a nonsense argument. Plus, there's not a lot of point in asking for feedback if I was going to do a blog instead.

Nothing personal but I beg to differ. Folk who come to LQ with package management problems (and the only folk who come here will be due to their having problems in the first place) will not, imo, want to read a lengthy generic wall of text about package management problems in general. There's far too much to take in for a start. I think you over-estimate the ability of newbies in particular to absorb new knowledge, particularly when that knowledge isn't specifically aimed at them and the system they are running.

Instead, they will want specific instructions and advice to do with their particular issue. Only a very few people would read, and take in, your proposed post. It would be a good topic for a very worthy blog post indeed (for which you could also ask feedback, that's not just restricted to stickies) but as a sticky it will just take up space. The blog post can be referred to by yourself and others on here.

The idea behind the sticky isn't to prevent people asking questions; it's meant to give some background, so they can either solve it themselves, or if they need some help, they can have some idea of where to start, and what information to provide - as stated in the OP. They don't necessarily have to read all of it, they can just read what's relevant to them. I think as long as it's understandable to a "newbie", then it would still fulfill it's intended purpose.

If they still need specific instructions, then they can still post a question - that's what the forums are here for. I think you underestimate people with all respect. A blog post will also take up space, and again, not everyone will even see blog posts, nor, and particularly, read them. I can tell you when I started out with Linux and searched for answers to problems I had; I paid more attention to threads over blogs, yes, some blog's were quite useful, but more often than not, I found the answers in threads rather than blogs. A sticky post can also be referred to quite easily, so there's no difference in that particular respect, therefore, the issue is "visibility", rather than how much space it takes up.

I agree with hydrurga's points.

I also say that the average newbie doesn't give a care about extensive history or details. They just want to make the thing work.

I try to shape my technical arguments solely about what would be the correct thing to do. This way I can become detached versus too invested in a certain way. Doesn't always work, but I try to remind myself this.

I will state my preferences, and that would be for a blog. I agree that too many stickys pollutes the top of a forum. Absolutely people point to it, as they do for the Kali one and the Kernel one. The stubborn OP's say back, "I already read that and it didn't help me" (and typically they misspell many words in said reply too.) There is no right or wrong here, it's an online forum.

What I mean by a brief overview of the topic, I reference Hazel's blog where she overviews package managers and why we have them.

As far as a summary of package managers, I mean to literally say, "There is apt, dpkg, opkg, ...", probably in list form and a quick partial line describing each.

And I do mean for simple command examples for each, accompanied with references for more detailed information.

My point here is that what you do have seems to be too bloated.

What "I" look for is "How to fix my broken situation?" Therefore, ... "I'm using xxx", "What's the fix?" Seems that very little in this proposed sticky helps this type of user, unless they want a masters course in package managers. Maybe I'm off base here, but that's my perspective on whom this information should be helping, and what they really need for help.

1 members found this post helpful.

Thanks for your feedback RT.

While I mean no disrespect to anyone, and I do value the feedback given (both for and against); while I can understand that having too many stickies could create issues; I do get the feeling that some members just don't think people read stickies, and therefore doing them is a waste of time. I will make a couple of points as to why I still think a sticky would be more suitable than a blog post; for one, it's not just about people reading them that are actually having a problem. So for example; someone posts the age old question, "which distro should I use?", then I know Mill J's sticky is in easy reach, because I can just open the Newbies forum, copy the link, then paste it to the thread I'm responding to. Rather than trying to remember "who posted that really good blog about choosing a distro?", then having to hunt through the blog's section of the site if I can't remember who it was that posted that blog. So if it's a sticky, then it's within easy reach for those that are trying to help the OP asking the question. For seconds, if people don't see it, then there's no chance they are going to read it. So again, it's far more visible as a sticky rather than a blog. For third's, the Software forum has only one sticky to date, being Jeremy's sticky, more to the point, the Slackware forum has eight stickies to the Newbies forum's five stickies, but yet, the guys that hang out in the Slackware forum seem to manage. I even recall someone proposing another sticky for the Slackware forum (don't remember what it was for, nor did I comment either way about it), and yet from memory, the arguments were about it's merit rather than "too many stickies" and alike. So with all respect, I think that particular argument is petty given the merits and the above reasons of a sticky vs a blog post.

While I understand your point RT, I think the section about why we have package managers pretty much covers that, and gives a reasonable overview already.

I think one problem with listing every known package manager is that; let's say a new one comes along after the proposed sticky is posted, then it may not (and probably won't) be helpful to a newbie using that new package manager. Therefore the proposed sticky is effectively "out-of-date", this is why I wanted to keep it general as possible. At the end of the day, and going back to Mill J's sticky, it's not aimed a one particular distro, it doesn't list every distro, but it does make some very good points, that even you've referred to yourself RT, and rightfully so IMHO. So I can't see why this proposed sticky can't follow a similar approach, and still be helpful. As you said yourself, people are either going to read it or not, regardless of whether it's in a blog or a sticky.

The Ubuntu apt-get how-to link pretty much covers most of the commands for apt-get, and obviously gives several command examples already. I'm not saying that more links with similar examples for other package managers/frontends can't be added, and I agree it would be a good idea to maybe add some more of that. But bear in mind, I have also linked the man pages for apt, apt-get, rpm, yum, etc as well, which also list the available commands for them.

While I can see your last point, it's not supposed to be a complete guide to any particular package manager (and this point is made in the first section), and was the reason I made it more general, rather than just focusing on yum (and maybe dnf as well).

I will agree that a sticky is more able to be referenced. Meanwhile I do agree that if the list of sticky threads continues to grow, it will make viewing forums rather cumbersome. Perhaps there is a forum wide option that may be more applicable. Sorry for the change of topic, but that's just what crosses my mind.

With some re-review on my part, it seems instead that this proposed sticky is intended to aid those who clearly have encountered problems with their package manager or their repositories.

It does not appear to be intended for users who don't know how to install something.

Correct? Incorrect?

Example: We see a "Help Me" category of question saying poorly that they don't know how to install <something>. Once we obtain distribution and version, we can tell them one or more forms of how to install what they want. Providing there are no repo or other problems, it works.

I'd really not have a great feeling to see that type of question get a blank sticky/blog link reference to this. How would it help that category of question?

To me, it would not, because it is not intended to aid someone with that type of blocking problem. Knowledge versus an actual system problem.

I think it should be patently clear that this sticky is intended to help those who do know the normal install process for their system, but there are problems anyways.

Getting through all the embroidery by the way, the only thing I got out of the whole prose which was useful, and would be useful to me (Mr. Not-well-informed-about-repos), was the inxi command, or any equivalent alternative which actually worked, so I could post the result.

I clearly have seen threads where people had install troubles, eventually their repos were listed, and eventually someone of expertise noticed that there was a problem, so they helped them actually fix it.

To me this is also the same as WiFi problems. They go around, and then eventually someone asks them to post the output of a command, which yields good information about their adapter, and etc. And from that point, many times they do get aid, if possible for their adapter and situation.

Am I at least now understanding the category of problems this sticky would address?

And in spite of me, and all of us, talking a lot about the topic. I feel that "less is more", and that it should be brief and to the point.

2 members found this post helpful.

Yes, correct.

I think for the type of question like "how do I install xxx?", that's probably more for the LQ wiki. As I said before, the point of my proposed sticky is for people that (as you say above) have tried to install package xxx (whatever package it is), then their package manage spits out errors saying it can't install package(s) xxx, they don't know what to do, so they look at the sticky, get some background about the basic fundamentals of package managers, figure out what *might* be some reasons for the problem, and if they still can't solve it, they can say "ok, well if I provide the info listed here, maybe someone can help me figure it out".

Again, it's not supposed to make anyone a world-renowned expert on package managers.

No, the proposed sticky isn't meant to deal with this type of question. I think the "Welcome to LQ" section in the FAQ already does a good job of addressing that sort of question, so no need for a sticky there IMO.

Fair call, I'll see what I can come up with, and if anyone else can think of anything, you're more than welcome to post it.

Yes, so in the event the OP can't solve it themselves, they could look at the proposed sticky and know what info to provide.

I believe so, yes.

Seems to me that the proposed sticky should be re-organized. Please start with a clear message as to what category of problem it is intended to help address. I feel it should next give guidance as to how to diagnose and conclude that a person is facing this category of problem. And then provide a recommended process which they should follow. Additional information is fine, however I do feel that getting to the primary point is important to accomplish early in the process.

1 members found this post helpful.