1. Understanding software distributions

There are several ways to get software on Linux, but the ones you’re most likely to come across are:

  1. From your package manager
  2. User-created packages for your package manager
  3. Flatpak, a separate, distro-agnostic package manager mainly used for desktop applications

… and manually-installed stuff, like AppImages, and tarballs.

It’s recommended you pick something that’s managed by a package manager, such as apt or Flatpak, so that you receive software updates.

2. The package manager (pacman, apt, dnf…)

In most scenarios, your software will probably be available in your package manager. Which package manager you have depends on your distribution:

  1. apt for Debian and derivatives, like Ubuntu and Linux Mint
  2. dnf for Fedora and derivatives, like Nobara
  3. pacman for Arch Linux and derivatives, like CachyOS and EndeavourOS

There are other package managers, but these are common ones, and the ones this guide will cover. Check and see which one your distribution is using.

In a lot of cases, the package manager you primarily interact with is just a frontend for interacting with the actual packaging system and package formats. For example:

  1. apt is a front-end for dpkg, and works with .deb files
  2. dnf is a front-end for rpm, and works with .rpm files

There are often graphical interfaces for interacting with your package manager, such as:

  1. KDE’s Discover
  2. GNOME’s Software
  3. Bazaar, a new store for Flatpaks
  4. Shelly, a graphical store for Arch Linux

However, these graphical interfaces can sometimes be unintuitive (such as in the case of choosing/knowing where the package is coming from), and don’t provide you the full control that a command-line invocation would.

Most package managers require you to be root (i.e., “administrator”) whenever you’re doing anything beyond just searching for packages. The most common way to do this is to prefix your command with sudo, which will run it as root.

Your distribution will have documentation for installing packages via your package manager, and usually a quick web search will show you the basics.

If all else fails, you can always read the manual for your package manager. “Manpages” are usually accessible online, or in your terminal:

  • For apt, either run man apt in your terminal, or see here.
  • For dnf, either run man dnf in your terminal, or see here.
  • For pacman, either run man pacman in your terminal, or see here.

3. User repositories (AUR, PPA, COPR…)

Arch’s main claim to fame is the AUR, but other distributions have user packages as well.

3.1 Debian and derivatives

A lot of Debian (& derivatives) packages are hidden behind the contrib and nonfree “suites”. To enable these, certain graphical managers may let you enable them, but otherwise, you’ll have to modify your apt sources.

Currently, the apt sources format is transitioning from the old sources.list format to the new deb822 format. Documentation on both of these formats is available here.

For PPAs, Ubuntu, Linux Mint, and Debian Sid have the useful add-apt-repository command, provided by the software-properties-common package:

sudo apt update
sudo apt install software-properties-common

# You can now use add-apt-repository:
sudo add-apt-repository ppa:user/ppa

If you don’t have access to add-apt-repository, for example, on Debian versions other than Sid, you may have to modify your apt sources directly. Documentation for doing that is available here.

Of course, after adding a repository, remember to apt update so that it registers.

3.2 Fedora and derivatives

Fedora primarily has RPM Fusion. This includes a lot of common software, such as Steam and the NVidia proprietary graphics drivers. RPM Fusion is separate from the primary Fedora repositories likely due to legal reasons.

Instructions for enabling RPM Fusion are available on their website here.

On top of RPM Fusion, a massive list of community-created packages is available at https://copr.fedorainfracloud.org/coprs/.

These are enabled directly via the command-line using:

sudo dnf copr enable user/copr

… usually, the exact command is provided on the COPR page as “Quick Enable” on the right.

Since dnf implicitly performs the equivalent to apt update on every invocation, you can install your new software immediately.

3.3 The Arch User Repository

Well known for being a comprehensive source of a lot of popular user software, the Arch User Repository is very powerful, but AUR software is not inherently managed by pacman.

To solve this, AUR helpers have been created, such as yay. Installing yay is relatively easy:

# AUR packages are provided as git repositories,
# and yay is built using Go, so we install those:
sudo pacman -S git go
# If you receive errors trying to install these,
# you may need to update your system first with pacman -Syu.

# Clone the sources for yay, and enter the folder:
git clone https://aur.archlinux.org/yay.git
cd yay

# Arch provides a handy "makepkg" command for handling PKGBUILDs.
# The -i flag tells it to install the resulting package:
makepkg -i

# Optionally delete the folder git clone created.
cd .. && rm -r yay

You should now be able to invoke yay. Running yay alone is equivalent to pacman -Syu.

Whenever you run yay with a query, such as yay steam, yay will show you options that it found.

yay will automatically handle updating AUR packages for you. A popular alternative is paru.

4. Flatpak

Flatpak is a relatively new, distribution-agnostic package management system that provides a lot of desktop applications.

A majority of public Flatpak packages are available in Flathub, which Fedora has disabled by default, likely due to legal reasons.

You can add Flathub to your Flatpak repositories with this command:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Then, various graphical package managers, such as KDE’s Discover, will allow you to select which source to download an application from.

Flatpak runs your application in a container, and only provides the program permission to see and do what the Flatpak states it needs. In some cases, these permissions can be limiting, for example, the Vesktop Flatpak by default can only see your Pictures folder, resulting in unexpected issues when trying to drag-and-drop files from elsewhere on your system.

To fix this, you can modify the Flatpak permissions using a program called Flatseal. Flatseal has an intuitive and simple interface for providing various permissions.

5. Software packages not in a repository (.deb, .rpm…)

Applications installed by a package not within a repository will not receive updates with new features and fixes by your package manager.

If all the above fails, sometimes, the software creator will provide a package for various distributions, such as a .deb or an .rpm.

Your system probably allows you to download and double-click it in your file explorer, which will prompt you to install it.

apt allows you to install a .deb directly:

# Using an absolute path, from root (/):
sudo apt install /path/to/package.deb

# Using a relative path, from the current folder (./):
sudo apt install ./package.deb

dnf works similarly, replace apt in the above commands with dnf and provide the path to your .rpm.

In some cases, such as the XPPen drivers .rpm, your package might have come without a signature, and apt or dnf may complain. If you trust the source of the package, you can get around it like so, replacing with either an absolute or relative path to your package:

# For apt:
sudo apt install --allow-unauthenticated <package>

# For dnf/rpm:
sudo rpm -ivh --nodigest --nofiledigest <package>

6. Desktop entries

Desktop entries, defined by .desktop files, are what tells your system what is an actual “application”. An application without a desktop entry won’t show up in your start menu or application runner. Most software distribution methods handle installing these for you.

Thankfully, you have the power to create your own in ~/.local/share/applications, and various desktop environments and runners will respect it, allowing you to create self-defined applications.

For example, here’s my .desktop file I use for Vesktop:

# ~/.local/share/applications/Vesktop.desktop
[Desktop Entry]
Type=Application
Name=Vesktop
Exec=/home/jack/.local/share/appimage/Vesktop.AppImage
Icon=/home/jack/.local/share/icons/vesktop.svg
Terminal=false

Notably:

  • Type should be “Application” for an application.
  • Name is the name of the program to display in your runner/start menu.
  • Exec is the command the application should run.
  • Icon is a path to an icon. Filetype support varies by desktop environment or runner. KDE Plasma supports .svg files.
  • Terminal=false tells your system that this program is not ran in a terminal/command prompt.

Additionally, there is a semicolon-separated Categories key, which sorts it into application categories, such as start menu sub-menus.

See the full .desktop file spec here.

See the list of all available .desktop file keys here.

See the list of available categories here.

7. AppImages

Installing a desktop application from an appimage requires you create a corresponding desktop entry. See 6. Desktop entries'

Additionally, most applications will not automatically update themselves with new features and fixes.

AppImages are entire programs packed with their dependencies, meant to run standalone. This means their filesize can be quite big, but they’re guaranteed to run on almost any Linux system.

AppImages depend on FUSE (“filesystem in userspace”), so you may have to install FUSE via your package manager for these to work.

You should pick a folder to put your AppImages. I typically put mine in ~/.local/share/appimages.

Once you have your AppImage, remember to mark it as executable (either using the Properties menu in your file manager, or a chmod +x), and create a desktop entry.

8. Tarballs

Installing a desktop application from a tarball requires you create a corresponding desktop entry. See 6. Desktop entries

Additionally, most applications will not automatically update themselves with new features and fixes.

A “tarball” is effectively the Linux equivalent to a .zip file.

Since a .tar file doesn’t compress on its’ own, a .tar file is typically compressed with another application, such as gzip, creating a .tar.gz. Other formats exist, such as .tar.bz2.

You should pick a folder to put your extracted tarball programs. I typically just extract mine into ~/.local/share, but you should verify there’s not already a folder of the same name in there.

Your system may have a program to help you extract tarballs from your file manager, but in case you don’t, you can use tar directly:

# You'll first probably want to move the tarball
# to where you want to extract it to:
mv ~/Downloads/tarball.tar.gz ~/.local/share
cd ~/.local/share

# Extract it:
tar xvf tarball.tar.gz

Once you have your extracted tarball, remember to create a desktop entry.

9. Building from source

Installing a desktop application from source may require you create a corresponding desktop entry; some handle it themselves. See 6. Desktop entries.

Additionally, you will not receive automatic updates.

Building and installing an application from source can be a time-consuming and complicated process. You will need to:

  1. Download the source code.
  2. Figure out its’ dependencies, and probably install the development packages for them.
  3. While most applications provide build instructions, some don’t.
  4. Build the application, run it, verify it’s working.

… in a lot of cases with C programs, it can come down to the usual ritual:

# Some have a "configure" script that generates a Makefile
# and verifies you have the dependencies required:
./configure

# Run make:
make

# Install the application:
sudo make install

Unfortunately, the exact process varies wildly from application to application, so detailed instructions can’t really be provided here.

While some may install a .desktop file for you, others don’t, so you may need to create a desktop entry.

10. Addendum: Nix

Nix is a relatively new, distribution-agnostic package management system.

Package management with Nix is typically declarative, not imperative, meaning you declare the packages you want. However, Nix provides (experimental) traditional imperative package management using nix profile.

Instructions for installing Nix are available here. Remember that Fedora has SELinux enabled by default, but you can disable it if you want.

Once Nix is installed, enable the nix-command and flakes experimental features:

mkdir -p ~/.config/nix
echo 'experimental-features = nix-command flakes' \
    > ~/.config/nix/nix.conf

You should now be able to use nix profile.

Documentation on nix profile is available here.

A package search is available here.

.. if you want to follow the usual declarative approach, you could look into using home-manager, but that is outside the scope of this guide.