I've been meaning to ask this for awhile now, but have been too lazy to...

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.

I'm not exactly sure what the scope of it should be, as I was originally thinking of just doing it for yum (and maybe dnf, given a lot of the yum commands/options would also apply to dnf), but since a software package is still a software package, maybe it could be for more than just yum?

I've typed up a rough draft last night of what it could look like, but it would still need to be refined more tho. I am willing to type up/refine a sticky myself, as I know, if I'm the one suggesting it, then I may as well be willing to type it up.

I've attached what I typed up last night anyway.

Attached Files

yum_sticky.txt (9.4 KB, 44 views)

Looks good, needs some spelling and grammar checking, but from my limited knowledge of yum it all seems reasonable. I agree that it may need a broader focus and perhaps should be extended to simultaneously make references to apt.

I also think your main points - the adding of 3rd party repositories, etc, needs to be at the top or at least summarised at the top and some of the basics cut out and instead being external references (to man pages, etc).

3rd party repositories are actually a scourge. In the earlier days of Linux you had building from tarballs, then you had hunting for rpms... but when tools like apt came along and package signing, you had one of the great advantages over other operating systems, where the user downloads assorted crap from wherever - the "3rd party repository craze" erodes this somewhat.

It doesn't matter who the source of the repository is - if it's google for example, you have essentially given them root privileges, to install software as they see fit - via dependency resolution, to "clobber" existing files and symbolic links, to run scripts, etc.

The problem is that package management has become an abstraction and many users have become out of touch with where these files go when the package is extracted and installed. It's just not enough to enable the repository and disable it again (as I've read that some do) - it should simply not be there in the first place. 3rd party stuff belongs in /usr/local (and/or /opt on Linux) and should be installed there by the user, either by building from source or by extracting some binary distribution there (e.g. as with the firefox builds).

Lastly, I would suggest a blog, over a stuck thread and link in your signature, might get more exposure that way - stuck threads sadly do get ignored quite often - or both.

£0.02

2 members found this post helpful.

Thanks cynwulf. I tend to agree with what you've said. I think it's better if it's not specific to any particular package manager, so I've made it much more general instead. And I spell-checked it this time, as I didn't really spell check the last one.

I think a sticky thread would be better than a blog, because I think it would be more visible to both other members (particularly new members), and also people that haven't joined up may not look in the blog part of the site. Either way, once it's posted, it would be indexed by search engines. But, a link in my signature is a good idea, so I'll look at doing that too when it's finished.

So I've attached another draft. I think it probably needs a few more refinements, but once again, just to give an idea of what it could look like when it's where it needs to be.

Attached Files

package_manager_sticky.txt (5.2 KB, 37 views)

I done a little refining yesterday, and added a few bits and pieces as well. I was going to add something about the differences between "source packages managers" and "binary package managers", as well as "devel" packages, but I'm not sure if I should. I figure it might make it too long, and detract from it's intended purpose. So I'm not sure...

Anyway, I've posted what it looks like so far below. I think I've go any typos and spelling mistakes out of the way, but feel free to point it out if I've missed any. Any content, or other suggestions are welcome.

***start of proposed sticky***

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. It is by no means a complete guide to package managers and software packages, more information can be found in the "More Resources" section below.

The general principles regarding software packages and repositories also apply to package managers and software packages in general.

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 usually 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. Basically, if a program uses shared libraries (but not limited to) that are contained in a different software package(s), then that other package(s) is said to be a "dependency". Because in that case, the package(s) you're trying to install/update "depends" on that other package(s) being installed for said software to work. The package metadata also contains information about what files are contained within the software package(s) being operated on, 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 alike.

Note: Software packages can also contain other types of files as well, despite the name, 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, like 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 more often than not, stem from incompatible software repositories being enabled. This maybe 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". Basically this means you're package manager/frontend cannot satisfy the dependencies for the package(s) you're trying to install/update, without breaking the dependencies for packages that are already installed - thus you cannot install and/or update the packages you're trying to install and/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/frontend. As a result, this will very likely cancel out the installation/update, and therefore your package manager/frontend cannot proceed.

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 you're Linux distribution can make no guarantees that it will not cause problems, and more importantly, adding such repositories increases the possibility that you may encounter package dependency problems.

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.

What information should I include when posting a question about software package problems?

The following information will help LQ members to and 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/frontends, the easiest way is via the terminal. Because there are many different package managers/frontends, there is no single answer to this question. Therefore, it will depend on both your Linux distribution, as well as the package manager/frontend concerned. If your package manager/frontend 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.

As mentioned in hydrurga's blog post linked below (the first link below), 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:

• 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

I did a blog about package managers and how to use them. Could that be linked in?

1 members found this post helpful.

Sure it can Hazel!

I think now you mention it, I vaguely recall seeing your blog post some time ago now, but I'd forgotten all about it!

I think this is an excellent idea. Persons will still ask questions without reading the stickies, but others can easily point them to the sticky and save lots of keystrokes.

I will print out a copy so I can give it a close reading tomorrow. I noticed couple of typos (you're instead of your, for example), but it's too late for me to give it the brain cells it deserves tonight.

1 members found this post helpful.

Thanks guys.

I think I'll give it a week, and see if there are anymore suggestions/ideas. As I would like to get any thoughts people have before posting a final draft for LQ's consideration. As, I would request, if it's approved for posting and sticky'ing, the resulting sticky thread to be closed, to prevent questions being posted to it - as it's to provide information, not for people to ask questions in.

I'm still on the fence about whether or not to include something about "binary based package managers" and "source based package managers" - so if people could give some feedback about that, I'd be grateful. While I have a couple of possible thread titles in mind, I haven't decided on one yet, so if anyone has any suggestions, please don't keep it to yourself. I was thinking maybe "Common package manager problems" or maybe "Package manager problems? Read on...".

Any other ideas/comments/suggestions would also be welcome, and now's the time to post them if you do have some further ideas/suggestions.

Thanks.

If you feel it merits inclusion and could link to my recently-created blog post "Manage your software sources in Debian, Ubuntu and Mint" (https://www.linuxquestions.org/quest...nd-mint-38002/) then I would be grateful.

Already done hydrurga!

It's the first link under the "More Resources" section.

Ah, one step ahead as usual.

I think the source-based thing can be handled in a single paragraph, something like this:

1 members found this post helpful.

Thanks for that Hazel! I think I'll probably just add that as is, as it looks good enough to me, and I can't think of a better explanation anyway. Also, I think you have more experience with Gentoo and alike than myself anyway's.

I have fixed a few things in RFC 1, and still have what Hazel's suggested above to add. I was thinking about adding the bit Hazel posted above about "source-based distros/package managers" under existing paragraphs in the "Why packages managers and software packages?" section. I'll still give it a week for anyone else to post any ideas/suggestions they may have for it, then next week release a final draft (RFC 2) for consideration. So please, anyone who has some further suggestions, please post them, as I'd rather not have to request any further edits after, and if it's sticky'd. Any useful links people think would be worth adding to the "More Resources" section are also welcome.

Something I forgot to ask before; if it is approved for sticky'ing, if I post the final agreed sticky to the Software forum (as I think that's the most logical forum for it), since "newbies" are very likely to ask related questions, could there be a link to it placed in the Newbies forum as well?

Just a note that I haven't seen any mods commenting on this yet. You might want to confirm with them whether or not, in principle, this would be acceptable as a sticky. You would probably have to approach the mods in charge of the subforum where you would like to post it.

Any further thoughts on the idea, or feedback on the content itself? The idea seems reasonable to me.

--jeremy

1 members found this post helpful.