How Zypper Handles Repositories in openSUSE

This article provides an overview of how the Zypper package manager configures, prioritizes, and synchronizes software repositories within openSUSE Linux. It covers the underlying configuration file structure, the role of metadata caching and the SAT solver library, repository prioritization rules, and the essential command-line operations used to manage package sources efficiently.

Repository Configuration Files

Zypper relies on the libzypp engine to manage software sources. Repositories are defined using standard .repo files located in the /etc/zypp/repos.d/ directory. Each file contains INI-style configurations detailing:

• Repository Alias and Name: Unique identifiers used by the system and human-readable labels.
• Base URL: The network or local protocol path (http://, https://, ftp://, or dir:/) pointing to the package tree.
• Enabled State: A binary flag (enabled=1 or enabled=0) determining whether Zypper queries the repository during operations.
• Autorefresh: A directive (autorefresh=1) instructing Zypper to check for remote metadata updates automatically before running package transactions.
• Priority: An assigned integer from 1 to 99 that influences package selection.

Repository Prioritization and Vendor Stickiness

Zypper enforces strict rules regarding package origins to maintain system stability:

1. Priority Ranking: Repositories can be assigned a priority value between 1 (highest priority) and 99 (default priority). When multiple repositories provide the same package, Zypper always chooses the version from the repository with the highest priority, regardless of whether a newer version exists in a lower-priority repository.
2. Vendor Stickiness: By default, Zypper adheres to vendor stickiness. Once a package is installed from a specific vendor (such as the official openSUSE build service or the Packman repository), Zypper will not automatically switch that package to a version provided by a different vendor during general system updates. Cross-vendor upgrades require explicit administrative confirmation or specific flags, such as zypper dup --allow-vendor-change.

Metadata Synchronization and Libsolv

To manage dependencies quickly, Zypper delegates dependency resolution to libsolv, a library that utilizes Boolean satisfiability (SAT) algorithms.

When a repository is refreshed (via zypper refresh or automatic background checks), Zypper downloads repository metadata—typically repomd.xml and associated XML data files—and compiles them into a binary cache format called .solv files. These files are stored in /var/cache/zypp/solv/. Because .solv files contain pre-computed dependency structures, Zypper can resolve complex dependency trees and detect package conflicts in fractions of a second without re-parsing raw XML files on every query.

Common Management Operations

Zypper handles repository administration through specialized subcommands:

• Listing Repositories: zypper repos (or zypper lr) displays all configured repositories, their aliases, enabled statuses, and refresh policies. Adding -d or -p displays URLs and priority levels.
• Adding Repositories: zypper addrepo <URL> <alias> creates a new .repo entry in /etc/zypp/repos.d/.
• Modifying Repositories: zypper modifyrepo allows administrators to toggle flags, such as enabling auto-refresh (-r) or changing priorities (-p <value>).
• Removing Repositories: zypper removerepo <alias> deletes the corresponding .repo file and purges associated cache data.
• Refreshing Repositories: zypper refresh forces the download of the latest metadata from all enabled repositories where changes are detected.