How to install software on Linux

Nočnica Mellifera - Mar 31 '20 - - Dev Community

The Inner and Outer Repos

cover image by Dietmar Rabich, CC BY-SA 4.0
Your software options might change a little when using Linux as opposed to Mac or Windows. The software you used before might not be the best option on a Linux platform. Some developers just refuse to make their code Linux compatible. Other Linux distributions might package one solution but not another. Regardless, finding and installing the right software for your project on Linux is not all that difficult when you know about all the various package repositories available to you.

Of course, the repository provided by your distribution; In my case, those maintained by Arch Linux; is the primary source of packages on your system. Always go through the official channels first. If we were looking to install the popular Java IDE, Eclipse, instead of going to the developer's website to download an installer, we would use our package manager (Eg., apt search eclipse on Ubuntu, yum search eclipse on Redhat, pacman -Ss eclipse on Arch, zypper se 'eclipse' on SUSE, or emerge --search eclipse on Gentoo).

Also, keep in mind that on many 64-bit distributions, the 32-bit side of the repositories are not enabled by default! If you can't find something on a 64-bit machine, make certain the package doesn't depend on 32-bit code! If it does, you will need to enable those repositories. The way you do so varies from one distribution to the next.

Even if the official repositories don't have what you are looking for, there are often alternatives. I'm talking about platform-independent package managers like Flatpak, Snapcraft, Steam, and Homebrew. This way the package and all its dependencies are contained and documented. "Why not just," I hear you protest, "use this other repository? Or download the package in my browser?"

Package management provides stability. When you go outside the official repositories, you can run into some serious problems. The maintainers of the official repositories make certain that everything that works together in the repository actually works together. And when packages don't work together, their package managers can tell you so. We cannot be certain that an unofficial repository or package will be reliably maintained in lockstep with the rest of the system. We can, however, be reasonably sure that whatever that package does to the system will not be supported by the official maintainers. In other words, if the package breaks, you and whoever works on that package are on your own!

So, when the official package manager doesn't have what you are looking for, don't immediately resort to adding unofficial repositories, installing from the source, or packaging the software yourself. It's a way better idea to get another, platform-independent package management system offered by your system that does. That way, those packages are contained and easily managed from the safety of the abstraction that is package management.

Only when it is clear there is no reliable way to get the packages you need, do you resort to unofficial channels. At that, a standalone installation is generally more stable than installing to the system proper.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .