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:
- Metadata: package name, version number (SemVer), author, dependencies, description, more.
- Files to install: usually a libSOMETHING.so (shared library) file or a binary executable file (e.g. /usr/bin/firefox), but there could be multiple binaries, plus config files, maybe source files, man page, etc.
- Scripts that do anything: usually tweak configuration files, but really could be large and do just about anything including interacting with the user.
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 |
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
Find:
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
Info:
apt show PKG
dnf info PKG
pacman --query --info PKG
pamac info -a PKG
eopkg info PKG
xbps-query --show PKG
Install:
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
dpkg --get-selections
dnf list --installed
rpm -qa --qf "%{NAME}\n"
pamac list -i
pacman -Q
yay -Q
nix-env -q
eopkg list-installed
[xbps-query no way to do it]
List all manually installed:
zypper se -si | grep i+
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.
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"
Repositories
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:
max_parallel_downloads=20
fastest_mirror=true # but some say this is a bad idea
install_weak_deps=true
deltarpm=true
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:
export ZYPP_MEDIANETWORK=1
export ZYPP_SINGLE_RPMTRANS=1
Search for packages across all distros:
Repology
pkgs.org
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.
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:
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.
...
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
NixOS Wiki
Zero to Nix
Fernando Ayats' "Into the Nix"
Henrik Lissner's "Frequently asked questions"
Fernando Borretti's "NixOS for the Impatient"
nixos.asia'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"
MyNixOS
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 search.nixos.org.
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.
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.
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:
GuixSD.
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 foo.tar.bz
tar -xjvf foo.tar.bz2
unzip foo.zip
# 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:
./autogen.sh
# 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
make test # maybe
sudo make install
# Launch the app from CLI:
/opt/foo/foo
# 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:
- A Linux kernel.
- A bootloader.
- An init system.
- Core utilities.
- A graphic stack (X or Wayland).
- A display manager (for logging in).
- A window manager.
- A desktop shell (e.g. plasma).
- Default applications.
- System utilities (settings, network manager, etc).
Miscellaneous
M. Hanny Sabbagh's "How to Install WebApps on Linux"