Package formats and managers

A package is a file that encapsulates a lot of metadata and some files and maybe scripts. It is used to install files etc onto a target system. A package (and its filename) may contain: See for example Wikipedia's "deb (file format)"

A repository is a collection of packages, usually on some public server. By having separate repos and enabling/disabling them, it's possible for a user or system to choose repos that are "only FOSS" or "only officially-supported software" or "private" or "testing" or other groupings.

A package manager manages packages in your system, installing/removing/searching/listing them as you wish. Usually the packages come from repositories, but also you could install a package file you downloaded manually from anywhere. Each package could contain binary and/or source and/or config files and/or install scripts, or just be metadata pointing to other packages. Some managers may know how to build from source to make a binary.

An app store manager is a GUI app that may just be a front-end to a package manager, or may be a curated way of selecting and installing/removing just certain GUI apps.

Format Distros / Family Binary Managers
rpm Red Hat, Fedora, CentOS, SUSE, Mageia rpm, yum, dnf, zypper, YaST, urpmi, Drakrpm
rpm Fedora Silverblue, Kinoite, Sericea, Onyx rpm-ostree
deb Debian, Ubuntu, Mint dpkg, apt, apt-*, aptitude, Synaptic, wajig, cupt, nala
tgz/txz Slackware, VectorLinux, Zenwalk pkgtools, slackpkg, slapt-get, Swaret, netpkg
pkg.tar.zst Arch, Manjaro pacman, pamac, yay, yaourt, apacman, pacaur
tbz2 Gentoo, Sabayon emerge/Portage, entropy, equo, sisyphus
tbz2 MocaccinoOS Luet
nix NixOS nix
xbps Void xbps
Solus eopkg
Intel Clear Linux swupd
Alpine apk
PET Puppy Linux PPM
??? Nitrux pkgcon ?
cards.tar/cards.tar.xz NuTyX cards
Some front-end managers that work on top of multiple package formats: smart, PackageKit, apx, rhino-pkg, bauh.

Fedora GNOME layers: rpm, then dnf (replacement for yum), then PackageKit, then GNOME Software.

Combination package manager / configuration manager ? GNU Guix (article), OStree, Guile, Nix.

Devopedia's "Package Manager"
Dan Lorenc's "In Defense of Package Managers"
PolyWolf's "Software Packaging Is A Nightmare"

Dedoimedo's "Broken apt, missing dependencies, what now?"

From /u/Linux4ever_Leo on reddit:
Honestly, there really isn't anything stopping the Linux world from standardizing on one single package management system except for egos. Each distro line deems its own package management systems to be the "best". Red Hat derived distros use RPM packages; Debian derived distros use DEB packages, Slackware uses good ol' tarballs. Gentoo and Arch prefer sources based packages. Still other distros have developed their own proprietary ways of managing packages. In short, it's sort of a mess. ... Personally, I don't care what sort of package manager wins the game so long as SOMETHING is standardized which will help further the widespread adoption of software on Linux and make things easier for developers to port their software to the Linux platform.

There are a couple of other levels of "management":
  • VMs and emulators. See "VMs and Containers" page.
  • Bundles/containers (Snap, Flatpak, appimage, Docker). See "VMs and Containers" page.
  • Language-specific module managers (node.js's npm, Ruby's gem, Python's pip, Go's get, Rust's cargo, Perl's cpan).
  • App store managers (GNOME Software, Ubuntu Software, Snap Store, POP!_Shop, Discover, Muon).
  • Web site "hubs": Flathub, Dockerhub, AppImageHub.

Package Manager Commands


apt search PATTERN
dnf search PATTERN
pacman --query --search PATTERN
pamac search -a PATTERN
nix-env -qaP PATTERN
eopkg search PATTERN
xbps-query -Rs PATTERN


apt show PKG
dnf info PKG
pacman --query --info PKG
pamac info -a PKG
eopkg info PKG
xbps-query --show PKG


apt install PKG
dnf install PKG
pacman --sync PKG
pamac install PKG
nix-env -iA
xbps-install PKG
rpm-ostree install PKG

List all installed:

apt list --installed
dnf list --installed
pamac list -i
pacman -Q
yay -Q
nix-env -q
eopkg list-installed
[xbps-query   no way to do it]

Show which installed packages depend on PKGX:
"dnf repoquery --installed --whatrequires PKGX"
"xbps-query --revdeps PKGX"

ArchWiki's "pacman/Rosetta"
Unixmen's "apt and apt-get"

On Arch family: from someone on reddit:
pacman is the base package manager for Arch.

yay is an "AUR-helper" or "AUR-manager" and also wraps pacman. With yay you get a similar CLI as pacman's, but you can also manage and search AUR-packages with it, not just the distro repo's packages.

pamac is Manjaro's package manager, and supports packages from repo, AUR, Snap, and Flatpak. Has both GUI and CLI versions.

If something from AUR has missing files, make sure you've synchronized/updated first. "yay -Syy"

Update repo mirrorlist:
"sudo pacman-mirrors --fasttrack && sudo pacman -Syy"

Show all groups / patterns / virtual packages:
"zypper patterns"

Why Did Something Get Installed ?
With deb/apt/dpkg packages:

ls -lt /var/lib/dpkg/info/*.list | less

zcat -f /var/log/dpkg.log* | grep -i PKGNAME | grep -E "\ install\ |\ upgrade\ "
# grab part of datetime from that, and do:
zcat -f /var/log/dpkg.log* | grep -i DATETIME | grep -E "\ install\ |\ upgrade\ "

cat /var/log/apt/history.log

sudo apt remove PKGNAME --simulate

apt-cache rdepends --installed --recurse PKGNAME

aptitude why PKGNAME --show-summary

On openSUSE: "zypper info PKGNAME" tells if manually or automatically installed.

Downgrade packages:
"grep TIMESTAMP /var/log/dpkg.log | grep upgrade | sed s////"
"sudo apt install packagename=oldversionnumber"
Maybe simulate first, with "apt -s" or "dpkg --dry-run".

DistroWatch's "Package Management Cheatsheet"
Ubuntu's "Package Management"


Ubuntu's "Repositories/Ubuntu"
Abhishek Prakash's "Things to do After Installing Ubuntu 18.04" (item 2)

Ubuntu 20.04:
In "Software & Updates" application, I turned on every repo except the source-code repos.
How to add Debian repo: Ask Ubuntu's "How to remove snap completely without losing the Chromium browser?"

On Arch, enable AUR.

On Manjaro, enable AUR: run "Add/Remove Software", click on three-dots icon in upper-right, click on "Preferences", go to "Third Party" tab.

On Manjaro, you could change to "Unstable" branch: Manjaro Wiki's "Switching Branches". Supposedly if you want to use things from AUR, they'd be more compatible with Unstable branch. "cat /etc/pacman.d/mirrorlist" to see what branch you're on. I stayed on Stable branch.

On Fedora:
Edit /etc/dnf/dnf.conf to set:

fastest_mirror=true    # but some say this is a bad idea

Install RPMFusion free and non-free repositories (instructions), reboot, then

sudo dnf groupupdate sound-and-video
sudo dnf install -y libdvdcss	# FAILED
sudo dnf install -y gstreamer1-plugins-{bad-\*,good-\*,ugly-\*,base} gstreamer1-libav --exclude=gstreamer1-plugins-bad-free-devel ffmpeg gstreamer-ffmpeg
sudo dnf install -y lame\* --exclude=lame-devel
sudo dnf group upgrade --with-optional Multimedia
sudo dnf config-manager --set-enabled fedora-cisco-openh264
sudo dnf install -y gstreamer1-plugin-openh264 mozilla-openh264
# Then in Firefox, enable OpenH264 plugin from Cisco.

As needed for specific apps or projects, enable the copr repository for each.
"sudo dnf copr enable OWNER/REPO" and then "sudo dnf install APPNAME"
So a copr repository is like an Ubuntu PPA.

There also is RPM Sphere but I haven't tried anything from it.

On SUSE: maybe Packman.
And edit $HOME/.profile to set:


Search for packages across all distros:

List Repositories In Use

# Debian family:
apt-add-repository --list
grep -v '#' /etc/apt/sources.list /etc/apt/sources.list.d/*

# Arch family:
less /etc/pacman.conf   # ???

# Red Hat family:
dnf repolist --enabled

# SUSE family:
zypper repos

# Flatpak:
flatpak remotes

# Snap:
# there is only one public store
# I don't know how to detect what store is being used

# Docker:
docker info | grep Registry     # ???

Declarative Managers

These are systems where, instead of running commands to change a system, you edit a "desired configuration" file, and then the system changes to match that file.

Picard saying make it so
Declarative: describes WHAT you want.
Prescriptive or Imperative: describes HOW you're going to get to what you want.

These are similar to container systems, where you have a configuration file for a container, and do a "build" operation to produce an image that matches that config file.

And related to enterprise configuration management tools such as Puppet, Chef, Salt, Ansible, Vagrant, Jenkins, Kubernetes.

Somewhat related to SBOM (Software Bill Of Materials) ? An SBOM usually is an output of a packaging operation.

This kind of system makes it easy to have a "reproducible build": the configuration file gives you all the specifications to make a copy of the system. This could be great if you have multiple machines which you want to be identical.

Nix is the language.
Nix is the package manager.
Nixpkgs is the specification (and repo) of the NixOS distro.
NixOS is the distro that results from Nixpkgs.
There is a command "nix-store".
There is a command "nix", with sub-commands build, run, develop, log, flake.
There are commands of form "nix-something".
There are "flakes", which are building blocks of some kind.
There are "channels".
Haskell for all's "Stop calling everything 'Nix'"

Nix can be used as the package manager on other distros ? You don't have to run NixOS to use Nix.
Ariya Hidayat's "Nix Package Manager on Ubuntu or Debian"
Chris Titus Tech's "Nix Package Manager"

From Jesse Smith's "NixOS 23.11":
... This idea that NixOS is immutable is false. The NixOS distribution has no immutable properties and we can write to any part of the root filesystem. ...


NixOS, using its snapshots and atomic updates, can offer some of the same benefits as some distributions which are immutable. However, NixOS does not use an immutable filesystem. It achieves its atomic update magic using other means.

Guix is or includes a modification of Nix ?

NixOS Wiki

Zero to Nix
Fernando Ayats' "Into the Nix"
Henrik Lissner's "Frequently asked questions"
Fernando Borretti's "NixOS for the Impatient"'s "First steps with Nix"
Michael Lynch's "My First Impressions of Nix"
Cat Girl's "Eight Months of NixOS"
Karl Voit's "I Started With Nix, NixOS, Home Manager and Flakes"
Matt Rickard's "Why Is NixOS Popular Again?"
Mike Kelly's "Why do people love NixOS so much?"
Ramin Honary's "Nix OS, Guix OS, and declarative package management"
Remy Grunblatt's "Nix and NixOS, my pain points"
Tinkering's "Nix journey part 0: Learning and reference materials"
Julia Evans' "Some notes on using nix"
Ryan Yin's "NixOS & Flakes Book"

Looks like installing NixOS is pretty standard, and then you can install Flatpak applications. But system configuration changes are done by editing /etc/nixos/configuration.nix and then doing "nixos-rebuild switch". Package installation: "nix-env -iA PKGNAME", where PKGNAME might be of form "nixos.SOMENAME". Search for package: "nix-env -qaP PATTERN" or look at

From Cat Girl's "Eight Months of NixOS":
Nix does not follow the standard Linux filesystem hierarchy; it stores almost all of its libraries and binaries under /nix/store. This means that you can have multiple copies of something installed without them interfering with each other, but it also means that you need to know how Nix packaging works to compile anything. Even libc isn't in its usual place, so downloading prebuilt binaries usually won't work.

From someone on reddit 10/2022:
I've been driving it a few months now, been gradually rolling it out to my other devices. It's very interesting, and I've been absolutely loving the declarative configuration, but the learning curve is very high, since all the configuration is done using its own bespoke syntax. The installer will get you up and running with a basic configuration that has Xorg, a desktop environment of your choice, and some preinstalled system packages, but everything else, you're going to have to configure in some way - bluetooth, wireless, and probably a million little packages that are normally installed by default on Ubuntu and Mint.

Once it's configured, though, you can back up the /etc/nixos folder somewhere, and never worry about getting it working again, at least in my short experience, where I've re-installed the base OS a few times, or on different computers. The NixOS manual or wiki often has the snippets of configuration you need right there. You can use Nix as a more 'normal' package manager with nix-env, but I like having it all down in a single place in a comprehensible way. It's also nice to be able to split that config into individual component files - I have my 'base system' configuration file, my general GUI configuration is in another, a bluetooth configuration in another, etc.

What I'm talking about is just my experience using the basic, stable featureset of configuration - I haven't even begun to touch flakes at all, which many people tout as being one of the more powerful features of NixOS, or home-manager. There's a lot there you can sink your teeth into, if you want or need it, but I've been pretty content with the basics.

From someone on reddit:
Imho, it isn't exactly an immutable distro. Yes, the system is read-only, but you can tweak your config file and update your system in a matter of seconds. That sets it apart from something such as Fedora Silverblue, where updating your system can take quite some time.

In general, this means NixOS is great for tinkering. You can tweak an option, try it out, and change back if you don't like the results, all in a minute. There's essentially no risk. And small tweaks can lead to big results. You could switch to a new desktop environment / wm with the same degree of ease.

Other declarative distros or systems:
Wolfi (article).

Compiling From Source

Follow any instructions given in the README or INSTALL file that comes with the software.

The somewhat-standard configure/make process:

# Get the source code:
git clone https://a-repo/foo.git
# Or download a TAR or ZIP file and then do one of:
tar -xzvf foo.tar.gz
tar -xjvf
tar -xjvf foo.tar.bz2

# You may need to install tools and dependencies:
sudo apt install build-essential
sudo pacman -S base-devel
sudo pamac install base-devel
sudo zypper install -t pattern devel_C_C++
sudo yum groupinstall "Development Tools"
sudo dnf groupinstall "Development Tools"   # or:
sudo dnf install @development clang

# Configure:
cd foo/
# If there is an Autogen file:
# Check for dependencies and configure the makefile:
./configure --prefix=/opt/foo
# Or if there is a CMakeList.txt file, maybe:
cmake . -DCMAKE_BUILD_TYPE=Release {some options ...}

# Build and install:
make test    # maybe
sudo make install

# Launch the app from CLI:

# Maybe create a foo.desktop file, in
# /usr/share/applications or $HOME/.local/share/applications,
# that points to executable file /opt/foo/foo
# Then you'll be able to launch foo from the desktop GUI.

# Later, remove it:
sudo make uninstall
make clean

Simon Kitching's "Beginner's Guide to Installing from Source"
John Wachira's "How to Build a Package from Source in Linux"
Jack Wallen's "How to Install Packages from Source on Linux"
LinuxForDevices' "Build Packages From Source In Debian"
Steve Friedl's "Good practices for building packages from source"
Dmitry Frank's "I'm Tired of Makefiles"
Owl's Portfolio's "Strengths, weaknesses, opportunities, and threats facing the GNU Autotools"

From someone on reddit:
"Build systems such as cmake, meson, autoconf will create the makefiles automatically, based on certain conditions, such as which libraries/headers are available, whether to build certain targets or not, and more."

Distribution (Distro)

A distribution is defined by what gets distributed (installed) to the user's system. You can modify that a bit by making choices at installation time, but only within limits set by the distro creators.

At a bare minimum, a Linux distro must include: Almost always, there also will be: For a desktop GUI system, there also will be: For a desktop GUI system with a full DE (not just a WM), there also will be:


M. Hanny Sabbagh's "How to Install WebApps on Linux"