# Installing applications on Linux
by Seth Kenlon

How do you install an application on Linux?

As with many operating systems, there isn't just one answer to that question. Applications can come from so many sources it's nearly impossible to count, and each development team may deliver their software in whatever they feel best. Knowing how to install what you're given is part of being a true power user of your OS.

<a name="repo" />
## Repositories

For well over a decade, Linux has used software repositories to distribute software. A "repository" in this context is a public server hosting installable software packages. A Linux distribution provides a command, and usually a graphical interface to that command, that pulls the software from the server and installs it onto your computer. It's such a simple concept that it has served as the model for all major cell phone operating systems and, more recently, the "app stores" of the two major closed source computer operating systems.

!(Not an app store)[repo.png]

Installing from a software repository is the primary method of installation. It should be the first place you look for any application you intend to install.

To install from a software repository, there's usually a command:

   $ sudo dnf install inkscape

The actual command you use depends on what distribution of Linux you use. Fedora uses ``dnf``, OpenSUSE uses ``zypper``, Debian and Ubuntu use ``apt``, Slackware uses ``sbopkg``, FreeBSD uses ``pkg_add``, and Illumos-based OpenIndiana uses ``pkg``. Whatever you use, the incantation is usually a combination of searching for the proper name of what you want to install, because sometimes what you call software is not its official or solitary designation:

   $ sudo dnf search pyqt
   PyQt.x86_64 : Python bindings for Qt3
   PyQt4.x86_64 : Python bindings for Qt4
   python-qt5.x86_64 : PyQt5 is Python bindings for Qt5

Once you have located the name of the package you want to install, use the install subcommand to perform the actual download and automated install:

   $ sudo install python-qt5

For specifics on installing from a software repository, see your distribution's documentation.

The same holds true, generally, with the graphical tools. Search for what you think you want, and then install.

!(apper)[apper.png]

Like the underlying command, the name of the graphical installer depends on what distribution you are running. The relevant application is usually tagged with the *software* or *package* keywords, so search your launcher or menu for those terms, and you'll find what you need. Since open source is all about user choice, if you don't like the GUI that your distribution provides, there just may be an alternative that you can install. And now you know how to do just that.

<a name="extra" />
### Extra repositories

Your distribution has its standard repository for software that it packages for you, there are usually extra repositories common to your distribution. For example, (EPEL)[https://fedoraproject.org/wiki/EPEL] serves Red&nbsp;Hat Enterprise Linux and CentOS, (RPMFusion)[http://rpmfusion.org] serves Fedora, Ubuntu has various levels of support as well as Personal Package Archive (PPA) network, (Packman)[http://packman.links2linux.org/] provides extra software for OpenSUSE, and (SlackBuilds.org)[http://slackbuilds.org] provides community build scripts for Slackware.

By default, your Linux OS is set to look at just its official repositories, so if you want to use additional software collections, you must add extra repositories yourself. You can usually install a repository as if though it were itself a software package. In fact, when you install certain software, such as (GNU Ring)[https://ring.cx/en/download/gnu-linux] video chat, the (Vivaldi)[http://vivaldi.com] web browser, Google Chrome, and many others, what you are actually installing is access to their private repositories, from which the latest version of their application is installed to your machine.

!(Installing a repo)[access.png]

You can also add the repository manually by editing a text file and adding to your package manager's configuration directory, or by running a command to install the repository. As usual, the exact command you use depends on the distribution you are running, but here is a ``dnf`` command that adds a repository to the system:

   $ sudo dnf config-manager --add-repo=http://example.com/pub/centos/7


## No repositories

The repository model is as popular as it is because it provides a link between the user (you) and the developer. When important updates are made available, your system kindly prompts you to accept the updates, and you can accept them all from one centralized location.

Sometimes, though, there are times when a package is made available with no repository attached. These installable packages come in several forms.

<a name="packages" />
### Linux packages

Sometimes, a developer distributes software in a common Linux packaging format, such as RPM, DEB, or the newer but very popular FlatPak or Snap formats. You make not get access to a repository with this download, you might just get the package.

The video editor (Lightworks)[https://www.lwks.com/], for example, provides a ``.deb`` file for APT users and an ``.rpm`` file for RPM users. When you want to update, you return to the website and download the latest appropriate file.

These one-off packages can be installed with all the same tools used when installing from a repository. If you double-click the package that you download, a graphical installer launches and steps you through the install process.

Alternately, you can install from a terminal. The difference here is that a lone package file that you've downloaded from the Internet isn't coming from a repository. It's a "local" install, meaning that your package management software doesn't need to download it to install it. Most package managers handle this transparently:

   $ sudo dnf install ~/Downloads/lwks-14.0.0-amd64.rpm

In some cases, there may be more steps you need to take to get the application to actually run, so read the documentation about the software you're installing carefully.


## Generic install scripts

Some developers release their packages in one of several generic formats. Common extensions include ``.run`` and ``.sh``. NVIDIA graphic card drivers, Foundry visual FX packages like Nuke and Mari, and many DRM-free games from (GOG)[http://gog.com] use this style of installer.

This model of installation relies on the developer to deliver an installation "wizard". Some of the installers are graphical, while others just run in a terminal.

There are two ways to run these types of installers.

You can run the installer directly from a terminal:

   $ sh ./game/gog_warsow_x.y.z.sh

Alternately, you can run them from your desktop by marking them as executable. To mark an installer executable, right-click on its icon and select **Properties**.

!(Give an installer executable permission)[exec.jpg]

Once given permission to run, double-click the icon to start the install.

!(GOG installer)[gog.jpg]

For the rest of the install, just follow the instructions on the screen.

<a name="appimage" />
### AppImage portable apps

The AppImage format is relatively new to Linux, although its concept is based on both NeXT and Rox. The idea is simple: everything required to run an application is placed into one directory, and then that directory is treated as an "app". To run the application, you just double-click the icon, and it runs. There's no need or expectation that the application is installed in the traditional sense, it just runs from where ever you have it lying around on your hard drive.

Despite its ability to run as a self-contained app, an AppImage usually offers to do some soft system integration.

!(AppImage system integration)[appimage.png]

If you accept this offer, a local ``.desktop`` file is installed to your home directory. A ``.desktop`` file is a small configuration file used by the Applications menu and mimetype system of a Linux desktop. Essentially, placing the desktop config file in your home directory's application list "installs" the application without actually installing it. You get all the benefits of having installed something and the benefits of being able to run something locally, as a "portable app".


<a name="dotdesktop" />
### Application directory

Sometimes, a developer just compiles an application and posts the result as a download, with no install script and no packaging. Usually, this means that you download a TAR file, (extract it)[https://opensource.com/article/17/7/how-unzip-targz-file], and then double-click the executable file (it's usually the one with the name of the software you downloaded).

!(Twine downloaded for Linux)[twine.jpg]

When presented with this style of software delivery, you can either leave it where you downloaded it and launch it manually when you need it, or you can do a quick and dirty install yourself. This involves two simple steps:

1. Save the directory to a standard location and launch it manually when you need it.
2. Save the directory to a standard location and create a ``.desktop`` file yourself to integrate it into your system.

If you're just installing applications for yourself, it's traditional to keep a ``bin`` directory (short for "binary") in your home directory as a storage location for locally installed applications and scripts. If you have other users on your system who need access to the applications, it's traditional to place the binaries in ``/opt``. Ultimately, it's up to you where you store the application,

Downloads often come in directories with versioned names, such as ``twine_2.13`` or ``pcgen-v6.07.04``. Since it's reasonable to assume you'll update the application at some point, it's a good idea to either remove the version number or to create a symlink to the directory. This way, the launcher that you create for the application can remain the same even though you update the application itself.

To create a ``.desktop`` launcher file, open a text editor and create a file called ``twine.desktop``. The (Desktop Entry specification)[https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html] is defined by (FreeDesktop.org)[http://freedesktop.org]. A simple launcher for a game development IDE called Twine, installed to the system-wide ``/opt`` directory:

   [Desktop Entry]
   Encoding=UTF-8
   Name=Twine
   GenericName=Twine
   Comment=Twine
   Exec=/opt/twine/Twine
   Icon=/usr/share/icons/oxygen/64x64/categories/applications-games.png
   Terminal=false
   Type=Application
   Categories=Development;IDE;

The tricky line is the ``Exec`` line. This line must contain a valid command to start the application. Usually it's just the full path to the thing you downloaded, but in some cases it's something more complex. For example, a Java application might need to be launched as an argument to Java itself:

   Exec=java -jar /path/to/foo.jar

Sometimes, a project includes a wrapper script that you can run so that you don't have to figure out the right command:

   Exec=/opt/foo/foo-launcher.sh

In the Twine example, there's no icon bundled with the download, so the example ``.desktop`` file assigns a generic gaming icon that shipped with the KDE desktop. You can use workarounds like that, or if you're more artistic then you can just create your own icon, or you can search the Internet for a good icon. As long as the ``Icon`` line points to a valid PNG or SVG file, your application will inherit the icon.

The example script also sets the application category primarily to **Development**, so in the KDE and Gnome and most other Application menus, Twine appears under the **Development category**.

To get this example to appear in an Application menu, place the ``twine.desktop`` file into one of two places:

* Place it in ``~/.local/share/applications`` if you're storing the application in your own home directory.
* Place it in ``/usr/share/applications`` if you're storing the application in ``/opt`` or another system-wide location and want it to appear in the Application menus of all your users.

And now the application is installed as it needs to be, and integrated with the rest of your system.

<a name="compile" />
## Compiling from source

Finally, there's the truly universal install format: source code. Compiling an application from source code is a great way to learn more about how applications are structured, how they interact with your system, and how they can be customized. It's by no means a push-button process, though. It requires a build environment, it usually involves installing dependency libraries and header files, and sometimes a little bit of debugging.

To learn more about compiling from source code, read my (article)[http://opensource.com//link/to/my/article] on the topic.


## Installing

Some people think that installing software is a magical process that only developers understand, or they think it "activates" an application, as if the binary executable file isn't valid until it has been "installed". Hopefully, learning about the many different methods of installing has show you that *install* is really just shorthand for "copying files from one place to the appropriate places on your system". There's nothing mysterious about it. As long as you approach each install without expectations of how it's supposed to happen and instead look for what the developer has set up as the install process, it's generally easy, even if it is different than what you're used to.

The important thing is that an installer is honest with you. If you come across an installer that attempts to install additional software without your consent (or maybe it asks for consent, but in a confusing or misleading way), or that attempts to run checks on your system for no apparent reason, then don't continue an install.

Good software is flexible, honest, and open. And now you know how to get good software onto your computer.

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.