Linux online course

Linux Package Managers: Packages, Dependencies, Repositories, and RPM vs. Debian

Learn how Linux package managers install, update, verify, and remove software, manage dependencies, use repositories, and differ between RPM and Debian systems.

A Linux package manager is a system of tools that manages the software lifecycle on an operating system. It can acquire, install, upgrade, configure, verify, and remove software while keeping track of how that software fits into the rest of the system.

This lesson focuses on two major Linux packaging families: RPM-based systems and Debian-based systems. The same general ideas also apply to other ecosystems, including Arch pacman, Alpine apk, Gentoo Portage, and universal packaging systems.

What Is a Software Package?

A software package is a distributable unit containing the files and information needed to install and manage software. It is more than an individual program.

A package may contain executable files, shared libraries, documentation, default configuration files, service definitions, metadata, and installation or removal scripts. The package manager places these files in the appropriate locations and records what it did.

For example, an editor package might contain the editor executable, libraries it needs, manual pages, icons, configuration templates, and metadata describing its version and dependencies.

Why Use a Package Manager?

Manually copying files into directories such as /usr/bin or /usr/lib makes software difficult to update and remove. It can also overwrite files belonging to another package or leave behind libraries and configuration files.

Centralized package management is safer and more maintainable because it provides:

• Consistent installation and removal.
• Automatic dependency resolution.
• Security and bug-fix updates.
• Repository-based software discovery.
• Package ownership and file-list queries.
• Integrity and authenticity checks.
• A record of installed versions and managed files.

Package Metadata and the Local Package Database

Package metadata is descriptive and operational information about a package. It commonly includes the package name, version, architecture, description, maintainer information, dependencies, conflicts, replacements, file lists, checksums, and digital signatures.

The package database is the local record of installed packages, their versions, managed files, and related state. It allows the system to answer questions such as:

• Is this package installed?
• Which version is installed?
• Which package owns this executable or configuration file?
• Which files did this package install?
• Are installed files different from the packaged versions?
• Which automatically installed dependencies are no longer needed?

If you delete a package's files manually, the package database may still say that those files exist. Later upgrades, removal operations, and verification checks can then produce confusing results. Avoid deleting package-managed files by hand.

Repositories and Software Sources

A repository is a software source containing package files and searchable index metadata. Repository indexes describe available package names, versions, architectures, dependencies, and download locations.

Before searching or upgrading, a package manager may need to download or refresh these indexes. Refreshing metadata is different from installing updates: the first operation updates the information about what is available, while the second changes installed packages.

Common software sources include:

• Official distribution repositories: maintained for the distribution and release.
• Updates and security repositories: provide bug fixes and security patches.
• Optional third-party repositories: provide software outside the distribution's standard collection.
• Local package files: packages downloaded or built separately from a repository.

Repositories are not automatically interchangeable. A repository built for another distribution, release, or architecture can introduce incompatible libraries and package versions. Repository priorities can influence which source wins when several repositories offer a package, so mixing sources requires care.

Dependencies and Dependency Resolution

A dependency is a package, library, capability, or version that another package requires. A web server, for example, may depend on libraries for networking, encryption, user accounts, or database access.

Dependency resolution is the process of selecting compatible packages that satisfy the requested installation or upgrade. A repository-aware package manager can download the requested package and its dependencies, calculate an installation plan, and show the planned transaction before making changes.

Dependency metadata can express several relationships:

• Versioned dependencies: a package requires a minimum, maximum, or specific version.
• Optional dependencies: additional features work when related packages are installed.
• Conflicts: two packages or versions cannot be installed together.
• Replacements: one package takes the place of another.
• Virtual or provided packages: a package declares that it supplies a capability under a logical name.

Failures can result from missing packages, incompatible versions, held or excluded packages, broken package states, unavailable architectures, or mixed repositories. Read the solver's explanation instead of forcing a low-level installation.

Linux Package-Management Layers

A package format is not the same as a high-level package-management command. Low-level tools work directly with local package files and package records. Repository-aware tools search configured sources, resolve dependencies, download packages, and manage transactions.

Debian-Family Package Management

On Debian-family systems, dpkg is the low-level tool for local .deb packages and installed package records. APT is the repository-aware package-management system; apt is its user-oriented command-line interface.

# Refresh repository indexes
sudo apt update

# Search available packages
apt search <term>

# Inspect package metadata
apt show <package>

# Install a package and its dependencies
sudo apt install <package>

# List installed packages
apt list --installed

# Query status and installed version
dpkg -l <package>

# List files supplied by an installed package
dpkg -L <package>

# Find which installed package owns a file
dpkg -S /path/to/file

# Upgrade packages
sudo apt upgrade
sudo apt full-upgrade

# Remove while normally retaining system configuration
sudo apt remove <package>

# Remove the package and its system-level configuration
sudo apt purge <package>

# Remove automatically installed dependencies no longer needed
sudo apt autoremove

# Install a local package while allowing APT to resolve dependencies
sudo apt install ./package-file.deb

Remove versus purge: apt remove normally removes program files but preserves system-level configuration. apt purge also removes those configuration files. Preserve configuration if you may reinstall the application and want its settings.

RPM-Family Package Management

On RPM-family systems, rpm performs low-level queries, verification, installation, and removal. dnf is the modern repository-aware tool for dependency resolution. yum is a legacy or compatibility-oriented command still associated with several RPM-based systems.

# Check repositories for available updates
dnf check-update

# Search package names and descriptions
dnf search <term>

# Display package metadata
dnf info <package>

# Install a package and dependencies
sudo dnf install <package>

# List installed packages
dnf list installed

# Query installation status and version
rpm -q <package>

# List files owned by an installed package
rpm -ql <package>

# Find which installed package owns a file
rpm -qf /path/to/file

# Upgrade installed packages
sudo dnf upgrade

# Remove a package
sudo dnf remove <package>

# Remove unneeded dependencies; inspect the proposed removals
sudo dnf autoremove

# Install a local RPM while resolving dependencies when possible
sudo dnf install ./package-file.rpm

# Check an RPM file's digest and signature status
rpm -K package-file.rpm

# Verify selected attributes of installed files
rpm -V <package>

Common Package-Management Tasks

Commands that only search or query usually do not need administrative privileges. Commands that change the system normally require sudo. Review the transaction summary, especially packages marked for removal, before confirming.

Integrity and Authenticity

Integrity asks whether package data was corrupted or unexpectedly changed. A checksum or hash is calculated from the data and compared with an expected value. A mismatch can indicate corruption, an incomplete download, or alteration.

Authenticity asks whether the package or repository metadata came from a trusted publisher. A digital signature uses cryptography to authenticate the signed data. A signing key is the trusted public key used to verify that signature.

Signature warnings should be investigated rather than suppressed. Repository definitions commonly include locations such as base URLs or mirror lists and settings for signature keys. Debian-family systems use APT source definitions; RPM-family systems use repository definition files. The exact file locations vary by distribution.

Package Creation and Distribution

Packaging ecosystems include tools that build binary packages. A binary package is a prebuilt, installable payload prepared for a particular distribution family, release conventions, and CPU architecture.

A source package contains source code, build instructions, patches, and packaging metadata rather than a directly installed binary payload. Building it produces a binary package suited to the target system.

Package maintainers define the file payload, metadata, dependency declarations, scripts, checksums, and signing process. A package can therefore be installed consistently by tools that understand the package format and distribution policies.

RPM Versus Debian Packages

A .rpm and a .deb are normally intended for different distribution families and cannot be installed interchangeably. Converting the archive format does not convert library versions, dependency names, filesystem conventions, scripts, service integration, or distribution policy.

alien can attempt conversion between some package formats, but it is a limited and caution-required option, not a routine workflow. Prefer a native package from the distribution repository, a vendor package built for the current system, source-based building when appropriate, or a supported container or universal packaging method.

Practical Workflow

1. Identify the distribution family, release, and CPU architecture.
2. Refresh repository metadata when required.
3. Search for the package using a keyword if the exact name is unknown.
4. Inspect its description, version, source, architecture, dependencies, and origin.
5. Request installation or an upgrade through the repository-aware tool.
6. Read the transaction summary, including packages to install, upgrade, or remove.
7. Confirm only when the source and planned changes are understood.
8. Use package queries afterward to verify the installed version and files.

For a local package file, inspect its architecture and metadata first. A local file may target another package family, release, or architecture. Low-level installation tools may not resolve dependencies automatically; repository-aware commands such as apt install ./package-file.deb and dnf install ./package-file.rpm can attempt dependency resolution through configured repositories.

Troubleshooting Package Problems

Package is not found

Refresh metadata, search by keyword, check whether the required repository is enabled, and confirm the package name for your distribution. Also check the operating-system release and architecture. A package may not exist for the current release.

Dependency resolution fails

Read the solver output carefully. Conflicting versions, mixed repositories, held or excluded packages, protected packages, and unavailable dependencies are common causes. Avoid forcing installation with a low-level tool. Review recently added repositories and return to supported sources or compatible package versions.

Signature verification fails

The repository key may be missing or changed, the source may be untrusted, the downloaded data may have been altered, or the system clock may be incorrect. Verify the repository through official distribution or vendor channels and obtain keys only from trusted sources. Do not disable signature verification merely to continue.

A local package will not install

Check the package family, CPU architecture, release target, and dependencies. Obtain a native package built for the current distribution and release whenever possible.

Configuration remains after removal

On Debian-family systems, standard removal normally preserves system-level configuration. Use purge only when you intentionally want that configuration removed.

A system file is missing or modified

Use an ownership query such as dpkg -S /path/to/file or rpm -qf /path/to/file. Then use the package format's verification features where available, such as rpm -V, and reinstall the affected package from a trusted repository if appropriate.

A converted package installs but fails

Conversion may leave dependency names or versions unresolved, run scripts written for another distribution, or expect different libraries and services. Treat conversion as experimental and prefer a native package or supported runtime environment.

Safe Package-Management Practices

• Use official or trusted repositories whenever possible.
• Keep the system updated, especially with security updates.
• Read transaction summaries before confirming.
• Do not delete package-managed files manually.
• Do not mix repositories designed for incompatible distributions or releases.
• Back up important systems and configuration before large upgrades.
• Use elevated privileges only for commands that change the system.
• Inspect automated cleanup proposals before accepting them.
• Investigate signature and key warnings instead of bypassing them.

Exam-Relevant Notes

• A package contains files plus metadata; it is not merely one executable.
• The package database records installed packages, versions, and managed files.
• A repository supplies packages and index metadata.
• Dependency resolution selects compatible required packages.
• Checksums primarily address integrity; signatures and trusted keys address authenticity.
• rpm and dpkg are low-level tools, while dnf/yum and apt/apt-get are repository-aware tools.
• RPM and Debian package files are not normally interchangeable.
• Removing files manually can make the package database inaccurate.

For related Linux fundamentals, see Linux, the Linux file structure, file ownership, and network time synchronization.