Debian where to install programs?

• If additional dependencies are required for the package to install, follow the on-screen instructions to choose whether to install them now.
• To remove an installed package, use sudo apt-get remove packageName .

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 cellphone operating systems and, more recently, the "app stores" of the two major closed source computer operating systems.

Installing from a software repository is the primary method of installing apps on Linux. 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:

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 usually involves searching for the proper name of what you want to install, because sometimes what you call software is not its official or solitary designation:

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:

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

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

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 graphical user interface (GUI) that your distribution provides, there may be an alternative that you can install. And now you know how to do that.

Your distribution has its standard repository for software that it packages for you, and there are usually extra repositories common to your distribution. For example, EPEL serves Red Hat Enterprise Linux and CentOS, RPMFusion serves Fedora, Ubuntu has various levels of support as well as a Personal Package Archive (PPA) network, Packman provides extra software for OpenSUSE, and 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 though it were a software package. In fact, when you install certain software, such as GNU Ring video chat, the Vivaldi 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.

You can also add the repository manually by editing a text file and adding it 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; for example, here is a dnf command that adds a repository to the system:

The repository model is so popular because it provides a link between the user (you) and the developer. When important updates are released, 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.

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, 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 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 you've downloaded from the internet isn't coming from a repository. It's a "local" install, meaning your package management software doesn't need to download it to install it. Most package managers handle this transparently:

In some cases, you need to take additional steps to get the application to run, so carefully read the documentation about the software you're installing.

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 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.

Once you've given permission for it to run, double-click the icon to start the install.

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

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 wherever 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.

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."

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, and then double-click the executable file (it's usually the one with the name of the software you downloaded).

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:

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 is defined by FreeDesktop.org. Here is a simple launcher for a game development IDE called Twine, installed to the system-wide /opt directory:

The tricky line is the Exec line. It 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:

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

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, but if you're more artistic, 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 KDE, 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:

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

Finally, there's the truly universal install format: source code. Compiling an application from source code is a great way to learn 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 on the topic.