Baeldung Pro – Linux – NPI EA (cat = Baeldung on Linux)
announcement - icon

Learn through the super-clean Baeldung Pro experience:

>> Membership and Baeldung Pro.

No ads, dark-mode and 6 months free of IntelliJ Idea Ultimate to start with.

Partner – Orkes – NPI EA (tag=Kubernetes)
announcement - icon

Modern software architecture is often broken. Slow delivery leads to missed opportunities, innovation is stalled due to architectural complexities, and engineering resources are exceedingly expensive.

Orkes is the leading workflow orchestration platform built to enable teams to transform the way they develop, connect, and deploy applications, microservices, AI agents, and more.

With Orkes Conductor managed through Orkes Cloud, developers can focus on building mission critical applications without worrying about infrastructure maintenance to meet goals and, simply put, taking new products live faster and reducing total cost of ownership.

Try a 14-Day Free Trial of Orkes Conductor today.

1. Overview

In this tutorial, we’ll talk about installing programs into Linux distributions. Linux has package managers, such as yum and apt, that help us install programs. As a rule of thumb, we should always prefer to use the default package manager if the program we are interested in is available there.

2. Packages Available via External Repositories

Not all packages are available in the main package manager of the distribution. Besides the main contribution repository, other repositories contain many programs that our package manager directly supports. One of the most well-known sources is the PPA (Personal Package Archive) repositories in Ubuntu.

In these package repositories, we find pre-compiled software packages that our package manager can easily install on our machine. We can find the repository list in the /etc/apt/sources.list file, where we can add the repositories we want. We’ll need to update our package manager after changing the available repositories. For example, for apt we can do this via:

$ apt update

We must remember that a Linux distribution team doesn’t verify the content of non-official repositories. They ensure the quality and security of the packages in the main repository, but the quality and security of non-official repositories depend on their maintainers.

Since we’ve installed the program via the package manager, the package manager will be responsible for updating the software in the future

3. Installation Methods for Packages Not Available in Repositories

There are two typical ways to install programs that aren’t available in the main repository of the package manager of our distribution. However, we should note that programs obtained externally will present some drawbacks.

Distributions usually analyze supported packages, even if minimally, to avoid large bugs or security backdoors. They ensure that the dependencies are satisfied. Moreover, they only accept programs that meet certain quality requirements and follow accepted conventions. None of these aspects is guaranteed for programs installed outside official repositories.

3.1. Downloading an Installer

The first option is to download the program installer. This process resembles the one in Windows and has similar advantages and drawbacks. We need to ensure that the installer we’ve downloaded is safe, for example, by comparing the checksum with one listed on the official website to verify a correct download and by analyzing the binary with an antivirus or malware detector. After installation, we may also need to perform future updates manually.

For example, let’s say we want to install program.deb file on Debian. We can install this program with dpkg:

$ dpkg -i program.deb

Another even better option is to use apt:

$ apt install program.deb

Installing program.deb with apt will handle the dependencies for us. Moreover, it will make the package manager aware of the existence of our program. This is important to avoid deleting the dependencies of our program. We’ll also be able to uninstall our program with the package manager.

However, this doesn’t mean we can update it with the package manager. We will still need to update the program manually to upgrade to a new version.

3.2. Building the Program

There is another option to get a program. One reason to do this if the readily available installers are incompatible with our platform or system architecture.

The safest way to build a program is to mirror the source code of the program we want and then compile the source code into a binary. Then, we can install it as we did with an installer downloaded from the internet.

One popular way to build a program is to download a script with curl and then run it with sh:

$ curl ADDRESS | sudo sh

However, although it may seem convenient, this approach contains some risks. Without inspecting the script we are downloading with curl, we may not know what it is doing. The web server may return a malicious script, the script might overwrite some configurations or programs, or the script may perform operations (such as installing Python packages) that we shouldn’t do with administrator privileges.

4. Considerations for Installing Packages Not Available in Repositories

If we install a binary installer, we need to keep some considerations in mind to have a stable installation.

4.1. Installation Path

When we download an installer or build a package ourselves, we may need to specify the installation path. We should choose a directory that won’t interfere with the package manager. Ideally, everything should be under folders such as /opt or /usr/local.

Another safe option is to use $HOME/.local as the installation directory. For folders as /opt or /usr/local, we may need administrator privileges, but we won’t need them inside the $HOME/.local path. This way we won’t break our system, because we can always log in with another account. It’s better not to use $HOME directly as the installation path to avoid losing data we may have stored there.

4.2. Colliding Apps

One common reason for installing applications manually is to install a different version than the one provided by the package manager. This is a dangerous procedure that may break the programs provided by the package manager. However, some package managers (as rpm) allow installing different versions of a program if there are no conflicting libraries. But this is limited to few scenarios.

There are better solutions in this case, like flatpacks, snaps, and appimages. All these solutions provide sandbox environments where the user can run programs isolated from the rest of the system. This ensures no clashes will occur between the dependencies of the program and those available in the system. However, it also means that the libraries in these environments will not get any bug fixes unless the vendor updates the solution environment.

4.3. Automatic Updates

The package manager typically won’t handle updates for programs installed outside the package manager. This is the main argument for using the package manager as much as possible.

There are exceptions, for example, some installers will add repositories during the installation, so the program is updated later via the package manager. But generally, we must download new installers and update the program whenever a new release is made.

5. Conclusion

In this article, we talked about installing programs outside of the main repository available in the system package manager. Firstly, we can use external repositories and the package manager. Secondly, we can download an installer for the program and install it manually. Thirdly, we can compile the source code and build an installer for the program ourselves.

However, we must understand that the further we move away from the repositories, the more unsafe a program installation might be. Thus, it’s always recommended to stick to the programs provided with the main repository of the distribution and the package manager.