dnf, pacman, snap and Installing Software from Source

The previous lesson covered apt and yum, which is enough for Ubuntu and older CentOS. Modern Red Hat systems use dnf, Arch uses pacman, and every distribution can also run sandboxed snap and flatpak packages. Occasionally nothing packages the version you need and you build it yourself. This lesson gives you a working vocabulary for each, and a comparison table so you can translate any instruction you find into the tool your machine actually has.

dnf: Fedora, RHEL, Rocky and AlmaLinux

dnf replaced yum in 2015; yum still exists as a compatibility alias. The subcommands are close to apt's.

bash

sudo dnf check-update                 # refresh metadata and list available updates
sudo dnf install -y nginx git         # install
sudo dnf upgrade --refresh            # upgrade everything (dnf update is an alias)
sudo dnf remove nginx                 # uninstall
dnf search "http server"              # search names and summaries
dnf info nginx                        # version, repo, description
dnf list installed | wc -l
dnf provides /usr/bin/htop            # which package supplies a file
sudo dnf autoremove                   # drop orphaned dependencies
sudo dnf history                      # every transaction, with undo support
sudo dnf history undo last

pacman: Arch Linux and Manjaro

pacman uses single-letter operations combined with modifiers. It looks cryptic for a day and then becomes the fastest package manager you have used.

| Command | Meaning | |---|---| | sudo pacman -Syu | sync databases (-y) and upgrade (-u) | | sudo pacman -S pkg | install | | sudo pacman -R pkg / -Rns pkg | remove / remove with dependencies and config | | pacman -Ss term | search the repositories | | pacman -Qs term | search installed packages | | pacman -Qi pkg | info on an installed package | | pacman -Ql pkg | list files owned by a package | | pacman -Qo /usr/bin/htop | which package owns a file | | sudo pacman -Sc | clear the package cache |

Arch is a rolling release: there are no versions, only the current state. Always run -Syu (full upgrade) rather than -Sy followed by installs; partial upgrades break libraries.

Software outside the official repos lives in the AUR (Arch User Repository), built from source by helper tools such as yay or paru: yay -S visual-studio-code-bin.

snap and flatpak: Sandboxed, Distribution-Independent

Both ship an application with its dependencies in an isolated bundle, so the same package runs on Ubuntu, Fedora and Arch. snap is maintained by Canonical and preinstalled on Ubuntu; flatpak is community-driven and the default on Fedora desktops.

bash

snap find "code editor"
sudo snap install --classic code      # --classic: full system access, for developer tools
sudo snap refresh                     # update all snaps (also happens automatically)
snap list
sudo snap remove code

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install flathub com.spotify.Client
flatpak run com.spotify.Client
flatpak update

Trade-offs: sandboxing improves security and freshness, but packages are larger, start more slowly, and may not see files outside your home directory without extra permissions. For servers, prefer native packages; for desktop applications the convenience often wins.

Building from Source

When no package exists, or the packaged version is too old, the classic sequence is configure, compile, install. First install the toolchain:

bash

sudo apt install build-essential        # Debian/Ubuntu: gcc, make, headers
sudo dnf groupinstall "Development Tools"
sudo pacman -S base-devel

Then, from the extracted source directory:

bash

tar xf htop-3.3.0.tar.xz && cd htop-3.3.0     # tar detects the compression from the file
./configure --prefix=/usr/local        # check dependencies, generate the Makefile
make -j"$(nproc)"                      # compile using every CPU core
sudo make install                      # copy binaries to /usr/local/bin

Newer projects use CMake (cmake -B build && cmake --build build && sudo cmake --install build) or a language toolchain (cargo install, go install). Installing to /usr/local keeps hand-built software separate from package-managed files in /usr, and /usr/local/bin is already on your PATH.

Translation Table

| Task | apt | dnf | pacman | |---|---|---|---| | Refresh metadata | apt update | dnf check-update | pacman -Sy | | Upgrade all | apt upgrade | dnf upgrade | pacman -Syu | | Install | apt install x | dnf install x | pacman -S x | | Remove | apt remove x | dnf remove x | pacman -R x | | Search | apt search x | dnf search x | pacman -Ss x | | Which package owns a file | dpkg -S /path | dnf provides /path | pacman -Qo /path | | List files in a package | dpkg -L x | dnf repoquery -l x | pacman -Ql x | | Clean cache | apt clean | dnf clean all | pacman -Sc |

Common Mistakes

Mixing package managers for the same software: a snap Node.js next to an apt Node.js leads to confusing which node results.
Running pacman -Sy pkg without -u and ending up with mismatched libraries.
Building from source into /usr and overwriting files a package owns.
sudo pip install or sudo npm install -g into system paths; use per-user or per-project installs.

Key Takeaways

dnf (RHEL family) mirrors apt with install, upgrade, remove, search, provides and undoable history.
pacman combines single-letter operations; -Syu upgrades, -S installs, -Ss searches, -Qo finds owners.
snap and flatpak deliver sandboxed applications on any distribution; prefer native packages on servers.
Build from source with ./configure && make && sudo make install into /usr/local only when no package exists.
Never sudo pip install or mix package managers for the same tool.

Next lesson: Environment Variables and .bashrc — learn where PATH and other settings come from and how to make changes stick.