Linux Software Packages: Hands-On Guide to apt, dnf, pacman, and Source Compilation

You have a Linux production server, try to install a package, and end up with broken dependencies, wrong version, or worse: a dead repository. Or you need software that isn't in the official repos and you don't know where to start compiling from source. It happens to everyone – we've been there ourselves after years working on Debian, CentOS, and Arch servers. The good news: once you understand how package managers and compilation work, you have full control over your system. This guide gets straight to the point, with real examples and no abstract theory.

Why Package Managers Matter

On Linux, every piece of software is a mix of binaries, libraries, configs, and dependencies. Installing manually means risking conflicts, wrong versions, and a maintenance nightmare. Package managers solve everything: they download from verified repositories, handle dependencies (the libraries the software needs), offer easy updates, and clean removal.

We, at Meteora Web, have decades of Linux server experience. The most common mistake: using apt on CentOS, or forcing an RPM package on Debian. Each manager has its own format: .deb for Debian/Ubuntu, .rpm for Fedora/RHEL/CentOS, .pkg.tar.zst for Arch Linux. Mixing them is the fastest way to break your system.

APT on Debian and Ubuntu

APT (Advanced Package Tool) is the manager for Debian-based distributions. It works on top of dpkg, which physically installs .deb packages. Essential commands:

# Update package list
sudo apt update

# Install a package
sudo apt install nginx

# Remove but keep configs
sudo apt remove nginx

# Remove configs and orphaned dependencies
sudo apt purge nginx
sudo apt autoremove

# Search
apt search "web server"

# Show details and dependencies
apt show nginx

Common mistake: forgetting sudo apt update before install. If the local repository is not synced, you install an old version or can't find the package. We see this often in production: spend one extra minute updating, save hours debugging.

To add external repositories (e.g., newer PHP than official Debian):

# Add GPG key and repository
sudo apt -y install lsb-release ca-certificates curl
sudo curl -fsSL https://packages.sury.org/php/apt.gpg | sudo gpg --dearmor -o /usr/share/keyrings/php.gpg
echo "deb [signed-by=/usr/share/keyrings/php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
sudo apt update
sudo apt install php8.3

DNF on Fedora and RHEL/CentOS 8+

DNF is the successor of YUM, used in Red Hat-based distributions. Same concept but different syntax. Essential commands:

# Update and install
sudo dnf update
sudo dnf install nginx

# Remove
sudo dnf remove nginx

# Search
sudo dnf search "web server"

# Info
sudo dnf info nginx

One key difference: DNF handles dependency conflicts better than YUM, but is slower in repository refresh. To add extra repositories, e.g., EPEL:

sudo dnf install epel-release
sudo dnf update
sudo dnf install htop

Caution: on CentOS 7 (old) use yum, not dnf. We have migrated all our servers to Rocky Linux 9, much more modern and actively supported.

Pacman on Arch Linux

Arch Linux uses pacman, simple and fast. But careful: rolling release means continuous updates. Convenient, but can occasionally break things. Commands:

# Sync and install
sudo pacman -Syu
sudo pacman -S nginx

# Remove
sudo pacman -R nginx
# Remove with unused dependencies
sudo pacman -Rs nginx

# Search
pacman -Ss "web server"

# Info
pacman -Qi nginx

A trick we often use: pacman -Qdt lists orphaned packages (no longer needed by anything). Cleaning them helps the system.

Source Compilation: When and How

There are cases where the package in repos doesn't exist, is too old, or you need specific compile-time options. Then compile from source. You don't need to be a kernel engineer – the process is standard and gives you maximum control.

Real scenario: a client asked us to install a custom Nginx build with ngx_pagespeed for performance optimization. Not available in official repos. Solution: compile.

The basic flow: configure, make, make install

All serious projects (C, C++) follow the same pattern:

# 1. Download source
wget https://nginx.org/download/nginx-1.26.2.tar.gz
tar -xzf nginx-1.26.2.tar.gz
cd nginx-1.26.2

# 2. Configure with options
./configure --prefix=/usr/local/nginx --with-http_ssl_module --add-module=../ngx_pagespeed-latest

# 3. Compile (use -j$(nproc) to speed up with all CPU cores)
make -j$(nproc)

# 4. Install
sudo make install

Typical errors: missing development dependencies. Configure fails with messages like "checking for OpenSSL... no". Solution: install -dev or -devel packages.

# On Debian/Ubuntu
sudo apt install build-essential libssl-dev libpcre3-dev zlib1g-dev

# On Fedora/RHEL
sudo dnf groupinstall "Development Tools"
sudo dnf install openssl-devel pcre-devel zlib-devel

Modern tools: checkinstall to package

Compiling with make install dirties your system because it doesn't track what you install. To create a real package that can be cleanly uninstalled, use checkinstall or manually create a .deb/.rpm.

# Install checkinstall
sudo apt install checkinstall  # Debian
sudo dnf install checkinstall  # Fedora if available

# After configure & make, instead of make install
sudo checkinstall
# It will ask for description, version, and create a .deb package you can install/uninstall like any software

Advanced Management: Dependencies and Repositories

Often the problem isn't installing, but understanding what's needed and where it comes from. Three situations we face daily:

1. Resolving missing dependencies

The classic: you try to install something and it says "depends on libfoo >= 2.0 but 1.0 is installed". On Debian:

# Check dependencies
apt depends nginx

# Attempt automatic fix (be careful not to break the system)
sudo apt --fix-broken install

On Fedora:

dnf repoquery --requires nginx
sudo dnf distro-sync  # resync packages to resolve conflicts

2. Adding third-party repositories

We often use non-official repositories for newer software (Docker, Node.js, MariaDB). Golden rule: only trust repos with a verified GPG key and active maintenance.

# Example for Docker on Debian
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

# On Arch, use AUR (Arch User Repository): be careful about security because packages are not official

3. Compilation with local patches

Sometimes you need to apply a modification to the source code. Download source, apply patch, then compile.

wget https://example.com/software-1.0.tar.gz
tar -xzf software-1.0.tar.gz
cd software-1.0
wget https://example.com/fix-security.patch
patch -p1 < fix-security.patch
./configure && make && sudo make install

Practical advice: always keep a backup of the original source and document applied patches. We use a README file in the server project to track every modification.

Common Errors and How to Avoid Them

• Using sudo on wrong commands: sudo apt upgrade is fine, sudo dnf upgrade too, but sudo pacman -Syu must be done carefully (updates entire system).
• Ignoring error output: if configure fails, the last line often tells you what's missing. Learning to read it saves hours.
• Installing from source without packaging: a year later, you forget what you compiled and can't cleanly remove it. Use checkinstall or create a dummy package.
• Mixing repositories: adding Ubuntu repos on Debian or vice versa leads to library conflicts. Never do it.
• Forgetting security updates: official repos release critical patches. With source-compiled software, you have to manage updates yourself.

In Summary – What to Do Now

You don't need to become an expert overnight. Three steps to get on solid ground:

1. Learn the three basic commands for apt, dnf, and pacman: install, remove, update. If you manage servers, know your manager and use only that.
2. Before compiling from source, check if an official PPA, COPR, or AUR exists. Much simpler and safer.
3. When you compile, use checkinstall to create a native package. Your future self will thank you.

If you want to dive deeper into Linux server management from scratch, our pillar guide Linux for Developers and Sysadmins takes you from shell to production. And if you need practical help on your project, contact us.