A general explanation or guide on installing software

[addem]

If possible, I’d like to have a sort of “once and for all” statement about the best practices with installing third-party software. I’ll start by making all kinds of claims based on my current (flimsy) understanding. Hopefully that will inspire internet hate to tell me how stupid I am, until I have corrected my wrong ideas. If no such “once and for all” guide to installation is possible, well that will be instructive in its own way.

A little background in case it’s helpful to see where I’m coming from:

I have been using Linux for a few years now, initially Ubuntu, then Mint, now PureOS. That sequence probably already tells you I don’t know a whole lot still. I’ve installed various software in various ways, usually by googling “how do you install R on linux” and following whatever results at the top of the search page. This has gotten me into some pretty knotted problems because the instructions were out of date or just plain bad. Sometimes instructions tell you to use a package manager, sometimes they instruct you to install from binaries, sometimes from source code. Sometimes the package manager only gives you out of date versions of the software that you want. Recently I experienced the issue that Java’s JDK is a little TOO new and by trying to run the most recent version of it, it caused Eclipse to stop working. Sometimes one installation method does something “weird” and when you get errors and ask people what’s happening on StackExchange you get a “Sorry, can’t understand what your computer is doing, your installation is weird” even when it was the officially recommended installation method. (I had and frequently have this problem with installations of LaTeX and related IDEs.)

Just hours ago I got my Librem 15 in the mail and have been toying with it, and I at least know that sudo apt update works as expected (although with just a single repo, which was a bit of a surprise). So I’m guessing if I want to install software that can’t be found in the software manager, it’s going to go a lot like it did on Ubuntu.

But in order to not make the same mistakes I’ve made before, I wanted to ask if there is a standard protocol for installing third-party software.

The package manager?

Should you always try to find a repo and let the package manager handle the rest? How do you know which repo to use? What do you do if the repo/package manager gives you outdated software–do you only then go look for an alternate installation method? You can always easily uninstall software that you installed from a package manager. Although I think in some cases like Java’s JDK, it leaves files and folders behind from the install, and if you try to re-install by a different process, this can cause conflicts. If you know which folders and files should be deleted you can do it yourself, but if you don’t know exactly what you’re doing, this sounds dangerous.

Although I often get the advice to just install from the package manager unless there is some overriding reason not to, I notice that the versions from package managers are almost always very much earlier than the versions that are available directly from the third-party’s website. I don’t need bleeding edge software, but this causes issues enough times that I no longer default to the package manager because it seems to avoid me having to deal with this down the road. Also in the case of texlive, I ran into issues when trying to install extra class files. It seems the issues were caused by the package manager’s method of installation.

Binaries

My understanding is that binary files are basically machine language files, meaning you can’t read them but your computer can. It also means that the binaries for a Windows machine won’t necessarily run on a Linux. But unlike source files, if you find the binaries that are right for you, you can install them more easily. I am not fully clear on how you install them. I think for some of them you can just download and click the downloaded file, it’ll pop up an install wizard, and walk you through the installation. For others, you may need to pop open a terminal and run sudo dpkg -i <filename> if it’s a .deb file. For others they come with configuration and installation files which you run with sudo ./<filename>. I may have some of this confused, so any clarification would be appreciated.

If you are installing certain software for development purposes, like the Java JDK or Python, you need this to be able to run commands from the terminal, and that means you need your terminal to know where to find them when you enter those commands. So for software like these, after installation you also need to find where your computer’s PATH variable is stored (I think the .bashrc file at the user’s home directory) and edit that file.

Source files

Source files are smaller and more human-readable than binaries, but when you download them you then have to build the software yourself. That means you need to have the compiler installed which will do the building, and different source files require different compilers. Then there’s the issue of dependencies, so this can be a much more difficult installation method for someone who doesn’t know what they’re doing. But if they come with a Makefile file, then if you have the compiler and all dependencies, you can run sudo make -f Makefile.

A test case

So let’s think about how someone following best practices would install some specific softwares. For selfish reasons, let’s suppose those softwares are:

• Java JDK
  Just from experience I know that installing open-jdk through a repo actually seems to work better because versions that are too new can break Eclipse.
• Anaconda
  Go to the site, download and install from binaries or source files.
• Eclipse
  Go to the site, download and install from binaries or source files.
• R and RStudio
  R can install pretty easily from a repo for “base-r” but RStudio I still haven’t had a lot of success with–whenever it upgrades, something seems to break.
• LaTeX and some kind of LaTeX editor like Atom
  Installing from the repo for texlive works until you need to install new class files. Then I think to correct whatever that doesn’t do correctly you have to build your own directory tree and put the class files in there.
• OCaml
  I think for this it’s best to use the package manager to install another package manager! You install OPAM and then OPAM will install OCaml. Sheesh.
• Chrome
  From a repo seems fine.
• Vim
  Repo.
• Sage
  I still haven’t figured out how to have both Anaconda and Sage installed on the same machine as they seem to have some kind of naming conflict. I don’t understand how to resolve that conflict so for now I’ve kind of just given up on trying to have both.
• TeamViewer
  There is no repo so you have to install from a binary or source file.

[Caliga]

Should you always try to find a repo and let the package manager handle the rest?

Yes.

How do you know which repo to use?

Omnipotence.

After a native distro-repo, I consider a third-party repo dedicated to one app the second best choice.
As you cab see in this example for Brave browser on PureOS, it is not exactly straight forward to add such a repo.
You think TeamViewer has no repo. That’s wrong. It is documented and you could set it up in a similar hassle as brave. But why bother?
You install the TeamViewer deb package, which adds the repo and the signature key. The updates (which are btw also deb packages) come automatically through the repo.

A deb is just an archive. You can right-click extract it to inspect it. (If you can’t, install a serious desktop environment like KDE Plasma )
It contains two more archives. One with the actual files (of which usually at least one is a binary/executable) and folders that will be installed (=copied), and one more with meta data which you can inspect in any text editor. Most notably, it contains the scripts (if any), which are run during installation and removal of the package.

The minimum guarantee the package manager gives you, no matter if you install from a repository or you install a deb directly, is that no package will overwrite a file owned by a different package. This is what you lose when building from source or installing a “binary” of some form. The better term would be “executable”. Often it is just a script with an archive appended to it. The script would copy to the content of the archive to your system, similar to what the package manager might do. But with more potential for messing something up.

in some cases like Java’s JDK, it leaves files and folders behind from the install, and if you try to re-install by a different process, this can cause conflicts. If you know which folders and files should be deleted you can do it yourself, but if you don’t know exactly what you’re doing, this sounds dangerous

Yes. But it has nothing to do with the installation method. It just means Java is a mess

On Linux, you should rarely need to adapt the path. Usually, all executables are already installed in a dir that is included. If it is installed in a different place, that might be on purpose not in path. If desired, I’d prefer to add a symlink to the binary to /usr/bin instead.

About your other examples: I don’t really know much about them, but it seems to me this is something the respective communities need to sort out (our teach you). The problem is that these are their own ecosystems. Your examples are not classical “apps”. If it’s broken, there might still be a best practice, but it won’t change the fact that it is broken

[addem]

Many thanks, I learned several things!

Quick follow-ups: On Purism’s website, where it discusses adding repos, it advises to put them in /etc/apt/sources.list but at your example link and elsewhere I see mention of this sources.list.d. I assume that is for, like, THIRD third-party repos. So for instance TeamViewer’s repo should go here, if I had installed it by adding the repo.

As I understand it right now, having considered your input, the best practices protocol is:

1. Look for it in the software manager, if it doesn’t have it:
2. Do a very light-weight search for a repo and trust in Jesus/Mohammad/Google that it’ll be a good repo, if you can’t find one:
3. Look for a .deb, if you can’t find one:
4. Look for other install files like source files, if you can’t find them:
5. Start doing more serious google-fu because you’re staring at the entrance of a rabbit hole. At this point you might start considering not installing the software at all, especially if there is some alternative software that has an easier installation method.

[Caliga]

I think the main reason why the directory exists is that files in there can be owned by packages. Otherwise, scripts would have to edit the global file. Scary. Note that if you would manually add the TV repo to a different file, you would end up having it twice, which is not a problem unless you edit/disable one of them and look confused because it does not have the desired effect.

Before or after 3. you might add Flatpaks. It’s basically just a different kind of package/repository. For some, it’s also controversial. Please keep the flaming in this thread.
Purism embraces it as a way to enhance the system with apps that are not (up to date) in the repo.
I did not mention it before as it will most likely not help you with the problems of those ecosystems with their own package formats you’re dealing with.

[reC]

for me a deb file ussually sufices for up-to-date software.

i believe that equaly as important to how to best install software is also knowing how to safely and efficiently remove packages.

for example - sudo apt auto-remove “followed-by-name-of-the-to-be-removed”
usually keeps things nice and tidy.