Package Formats, Repositories, and Dependency Resolution

1. A package is more than a compressed directory

A Linux package normally contains a payload of files plus structured metadata that tells the package system what the software is, which architecture it targets, which version it provides, what it requires, where files belong, and which lifecycle actions must run. Debian-family systems commonly use .deb packages managed at the low level by dpkg. Fedora, Rocky Linux, AlmaLinux, and related systems use RPM packages managed at the low level by rpm.

A package archive is therefore an input to a state transition. Installing it can add users, reload services, update caches, register alternatives, rebuild an initramfs, or trigger other package-maintainer logic. Treat package transactions as controlled system changes, not simple file copies.

2. Separate the package layers

flowchart TB
  U["Operator or automation"] --> H["High-level manager: APT or DNF"]
  H --> M["Repository metadata and dependency solver"]
  M --> P["Selected package set and transaction plan"]
  P --> V["Signature and integrity verification"]
  V --> L["Low-level manager: dpkg or rpm"]
  L --> F["Files, scripts, services, and configuration"]
  L --> D["Installed package database"]
  D --> H
  R["Configured repositories"] --> M

Use the high-level manager for normal installation and removal because it understands repositories and dependency closure. Use low-level tools primarily for inspection, verification, packaging work, and carefully diagnosed recovery.

3. Dependency solving is a constraint problem

A request such as “install package X” expands into constraints. X may require a minimum version of library Y, conflict with package Z, provide a virtual capability, recommend optional components, or be available for several architectures. The solver attempts to select a consistent transaction from enabled repositories and installed state.

4. Version ordering is distribution-specific

Package versions are structured strings, not ordinary decimal numbers. Debian and RPM ecosystems use different comparison rules and may include epochs, upstream versions, distribution releases, revision components, and architecture qualifiers. Never implement version ordering with lexical string comparison or floating-point conversion.

# Read-only comparisons on systems that provide the relevant tool.
if command -v dpkg >/dev/null 2>&1; then
  dpkg --compare-versions '2:1.4-3' gt '1:9.9-9'
  printf 'dpkg comparison status=%s\n' "$?"
fi

if command -v rpmdev-vercmp >/dev/null 2>&1; then
  rpmdev-vercmp '1:1.4-3' '1:1.4-2'
elif command -v rpm >/dev/null 2>&1; then
  rpm --eval '%{rpmversion}\n'
fi

An epoch can override the apparent upstream version and is generally difficult to remove once introduced. Distribution release fields distinguish multiple package builds of the same upstream version. Always query the package manager for the installed and candidate versions.

5. Ask who owns the file and where the package came from

Operational debugging often begins with a path: an executable, service unit, library, or configuration file. Package tools can map installed files back to packages, list package contents, show versions, and identify repository candidates. This is more reliable than assuming a file was installed manually.

target=${1:-/bin/sh}

printf 'target=%s\n' "$target"
command -v "$target" 2>/dev/null || true

if command -v dpkg-query >/dev/null 2>&1; then
  dpkg-query -S "$target" 2>/dev/null || true
  dpkg-query -W -f='${binary:Package}\t${Version}\t${Architecture}\n' 2>/dev/null | head
fi

if command -v rpm >/dev/null 2>&1; then
  rpm -qf "$target" 2>/dev/null || true
  rpm -qa --qf '%{NAME}\t%{EPOCHNUM}:%{VERSION}-%{RELEASE}\t%{ARCH}\n' | head
fi

A file may be unmanaged, generated at runtime, supplied by a container, mounted from another filesystem, or replaced after package installation. Package ownership is strong evidence, but verify current file metadata and integrity when compromise or drift is possible.

6. Hands-on lab: inventory the package-management stack

This read-only lab records the distribution, available package tools, repository configuration locations, package counts, and ownership of selected commands.

lab="$HOME/devops-academy/linux/chapter09/lesson01"
mkdir -p "$lab"
report="$lab/package-stack.txt"

{
  printf '=== operating system ===\n'
  cat /etc/os-release

  printf '\n=== package tools ===\n'
  for cmd in apt apt-get apt-cache dpkg dpkg-query dnf dnf5 yum rpm; do
    if command -v "$cmd" >/dev/null 2>&1; then
      printf '%-12s %s\n' "$cmd" "$(command -v "$cmd")"
    fi
  done

  printf '\n=== repository configuration ===\n'
  find /etc/apt /etc/yum.repos.d /etc/dnf -maxdepth 2 -type f \
    2>/dev/null | sort || true

  printf '\n=== installed package count ===\n'
  if command -v dpkg-query >/dev/null 2>&1; then
    dpkg-query -W -f='${binary:Package}\n' | wc -l
  elif command -v rpm >/dev/null 2>&1; then
    rpm -qa | wc -l
  fi

  printf '\n=== ownership examples ===\n'
  for path in /bin/sh /usr/bin/env /usr/bin/ssh; do
    [ -e "$path" ] || continue
    printf '%s\n' "$path"
    if command -v dpkg-query >/dev/null 2>&1; then
      dpkg-query -S "$path" 2>/dev/null || true
    elif command -v rpm >/dev/null 2>&1; then
      rpm -qf "$path" 2>/dev/null || true
    fi
  done
} > "$report"

less "$report"

7. Common mistakes

8. Knowledge check

9. Summary

Linux software management is a layered state-management system. Repositories publish authenticated metadata and package archives; high-level managers select candidates and solve dependencies; low-level managers apply package transactions and maintain installed state. Before changing software, identify the stack, inspect candidates and provenance, and review the full transaction plan.

10. Further reading

• Debian Reference: package management and APT policy.
• APT User's Guide and Debian apt(8), apt-get(8), and dpkg(1) manual pages.
• DNF5 documentation and RPM Reference Manual.