zypp.conf - Man Page

lock_timeout (0 sec)

If zypp is locked by another process this is the number of seconds to wait for the lock to become available. If the lock can not be acquired within the specified time an exception is raised. A negative value will wait forever.

The environment variable ZYPP_LOCK_TIMEOUT can be used to override this setting. ZYPP_LOCK_TIMEOUT=-1 is sometimes set by unattended running scripts to delay a zypper command rather than failing if the lock is not available.

cachedir (/var/cache/zypp)

Path where the caches are kept.

metadatadir ({cachedir}/raw)

Path where the downloaded repo metadata are kept.

solvfilesdir ({cachedir}/solv)

Path where the repo .solv file caches are kept.

packagesdir ({cachedir}/packages)

Path where the downloaded packages are kept.

configdir (/etc/zypp)

Path where the remaining configuration files are kept.

reposdir ({configdir}/repos.d)

Path where the known repositories .repo files are kept.

servicesdir ({configdir}/services.d)

Path where the known services .service files are kept.

varsdir ({configdir}/vars.d)

Path where custom repo variable definitions are kept.

A custom repo variable is defined by creating a file inside the varsdir directory. The variable name equals the file name. The file’s first line (up to, but not including, the newline character) defines the variables value. See section Variable substitution in the zypper(8) man page for more details.

vendordir ({configdir}/vendors.d)

Path where vendor equivalence description files are kept.

Each file in this directory defines a comma-separated list of equivalent vendor string prefixes (case-insensitive comparison):

-------------------- file begin ----------------
[main]
vendors = MyVendor,AlternateName
-------------------- file end ------------------

By this vendor strings starting with "MyVendor" or "AlternateName" are considered to be equivalent. Packages from equivalent vendors may replace each other without being considered as a vendor change.

Note: Within the "opensuse*" namespace exact matches (case-insensitive) are required. "vendors = suse,opensuse" will allow switching between "suse*" and "opensuse", but not e.g. "opensuse build service".

repo.add.probe (false)

Whether repository URLs should be probed when added (e.g. via zypper addrepo).  If false, the repository URL is checked upon the first refresh.

repo.refresh.delay (10 min)

The amount of time in minutes that must pass before another repo auto-refresh is attempted.

A value of 0 means the repository will always be checked. To get the opposite effect, disable autorefresh for the repository. This option has no effect for explicitly user-requested refresh requests.

repo.refresh.locales (en)

A list of locales for which translated package descriptions should be downloaded in case they are available and the repo supports this. Not all repo formats support downloading specific translations only.

The concrete list is in fact controlled via zypper's locales, addlocale and removelocale commands. The locales defined here are just sticky.

download.max_concurrent_connections (5)

Maximum number of concurrent connections to use per transfer.

download.min_download_speed (0 B/sec)

Sets the minimum download speed (in Byte per second) until the connection is dropped. 0 means no limit.

This can be useful to prevent security attacks on hosts by providing updates at very low speeds.

download.max_download_speed (0 B/sec)

Sets the maximum download speed (in Byte per second). 0 means no limit.

download.max_silent_tries (1)

download.connect_timeout (60 sec)

download.transfer_timeout (180 sec)

download.use_deltarpm (false) (true on SUSE-15.6 and older)

download.use_deltarpm.always (false)

download.media_preference (download)

Hint which media to prefer when installing packages (download vs. volatile aka. CD/DVD).

Note that this just a hint. First of all the solver will choose the best package according to its repos priority, version and architecture. But if there is a choice, we will prefer packages from the desired media.

Packages available locally are always preferred. The question is whether you prefer packages being downloaded via FTP/HTTP/HTTPS (download), rather than being prompted to insert a CD/DVD (volatile), in case they are available on both media.

download.media_mountdir (/var/adm/mount)

Path where media are preferably mounted or downloaded.

The media backend will try to organize media mount points and download areas below this directory, unless a different location is requested by the application. If the directory is not accessible and read/writable for a specific user, the fallback is to use /var/tmp.

download.use_geoip_mirror (true)

Whether to use the geoip feature of download.opensuse.org.

The media backend may rewrite download requests to the geographically closest available mirror. Which exact mirror is used will be determined by requesting a "geoip" file from download.opensuse.org via a HTTP GET request to https://download.opensuse.org/geoip , the server will use the clients IP to determine the closest mirror if available.

Some specific files are however excluded from this redirection due to security reasons, especially the repo metadata index and it’s key and checksum files: repomd.xml{,.key,.asc}.

gpgcheck (on)

repo_gpgcheck (<UNSET>, depending on {gpgcheck})
pkg_gpgcheck  (<UNSET>, depending on {gpgcheck})

Default signature checking of repo metadata and downloaded rpm packages.

Note: Explicitly setting gpgcheck, repo_gpgcheck and/or pkg_gpgcheck in a repositories .repo file will overwrite these defaults for this specific repo. The zypper addrepo and modifyrepo commands provide several gpgcheck related options to tune the behavior. See the zypper(8) man page for details.

If gpgcheck is on (the recommended default) we will check the signature of repo metadata. Using unsigned repos needs to be confirmed.

Packages from signed repos are accepted if their checksum matches the checksum stated in the repo metadata.

Packages from unsigned repos need a valid gpg signature. Using unsigned packages needs to be confirmed.

The above default behavior can be tuned by explicitly setting repo_gpgcheck and/or pkg_gpgcheck. But in general it’s recommended to relax the settings on a per repo basis, rather than relaxing the global defaults.:

repo_gpgcheck = on is the same as the default behavior.

repo_gpgcheck = off will silently accept unsigned repos. It will NOT turn off signature checking on the whole. Nevertheless, it’s not a secure setting.

pkg_gpgcheck = on will enforce the package signature checking and the need to confirm unsigned packages for all repos (signed and unsigned).

pkg_gpgcheck = off will silently accept unsigned packages. It will NOT turn off signature checking on the whole. Nevertheless, it’s not a secure setting.

If gpgCheck is off (not recommended), no checks are performed. You can still enable them individually by setting repo_gpgcheck and/or pkg_gpgcheck to on.

DISABLING GPG CHECKS IS NOT RECOMMENDED. Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise.

commit.downloadMode (<UNSET>)

The default commit package download policy to use. If the value is not set, empty or unknown, we pick some sane default depending on the task to perform. There should be little need to set a fix default here.

DownloadInAdvance: First download all packages to the local cache. Then start to install. This is the safe and preferred default when installing packages to the local system.

DownloadInHeaps: Similar to DownloadInAdvance, but try to split the transaction into heaps, where at the end of each heap a consistent system state is reached.

DownloadAsNeeded: Alternating download and install. Packages are cached just to avid CD/DVD hopping. This mode saves disk space but is error prone if packages can not be retrieved in the middle of the transaction. It is an option for chroot installs, but not for the local system.

solver.focus (<UNSET>)

The solver’s general attitude when resolving jobs. If the value is not set, empty or unknown, we use the resolvers default.

Job: Focus on installing the best version of the requested packages. Add missing dependencies as needed. This is the solver’s default.

Installed: Focus on applying as little changes to the installed packages as needed. Choosing an older version of a package is valid if it’s dependencies require less changes to the system.

Update: Focus on updating requested packages and their dependencies as much as possible.

solver.onlyRequires (false)

Whether only required packages should be selected by the resolver. Otherwise also recommended packages are considered.

solver.allowVendorChange (false)

solver.dupAllowDowngrade (true)
solver.dupAllowNameChange (true)
solver.dupAllowArchChange (true)
solver.dupAllowVendorChange (false)

solver.cleandepsOnRemove (false)

solver.checkSystemFile (/etc/zypp/systemCheck)

This file contains requirements and conflicts which fulfill the needs of a running system. For example the system would be broken if no glibc or kernel is installed. The resolver is always aware of these constraints and watches they are not violated.

Each line in the file represents one dependency: requires:kernel or requires:glibc.

solver.checkSystemFileDir ({configdir}/systemCheck.d)

Path where checkSystem file drop-ins can be placed. Files are read in lexicographic order of their filenames. See solver.checkSystemFile.

solver.upgradeTestcasesToKeep (2)

When committing a dist upgrade (e.g. zypper dup) a solver testcase is written to /var/log/updateTestcase-<date>. This testcase is often requesetd in bugreports regarding migrations or distribution upgrades. This option defines the number of testcases to keep on the system. Old cases will be deleted, as new ones are created. Use 0 to write no testcase at all, or -1 to keep all testcases.

solver.upgradeRemoveDroppedPackages (true)

Whether a dist upgrade should remove a products dropped packages.

A new product may suggest a list of old and no longer supported packages (dropped packages). Performing a dist upgrade the solver may try to delete them, even if they do not cause any dependency problems.

See also zypper dup --remove-orphaned, which provides a similar kind of cleanup. It cleans no longer required packages which are also no longer provided by any enabled repository (aka. orphaned packages).

multiversion (<EMPTY>) [provides:multiversion(kernel) via vendor configuration]

Comma separated list of packages which are built to be, and should be, installed in different versions at the same time.

Packages are selected either by name, or by provides. In the later case the string must start with "provides:" immediately followed by the capability.

[Beware!] While it is save to remove the definition here, the kernel will be treated like any other package then, be very careful when adding definitions. If you add packages which are not built to support being installed in multiple versions, the packages will easily damage each other.

multiversiondir ({configdir}/multiversion.d)

Path where multiverion file drop-ins can be placed. Files are read in lexicographic order of their filenames. See multiversion.

multiversion.kernels (<EMPTY>) [latest,latest-1,running via vendor configuration]

Comma separated list of kernel packages to keep in the system if zypper purge-kernels is called and multiversion is set for the kernel packages. Kernel packages can be specified as:
2.6.32.12-0.7 - An exact kernel version to keep
latest        - Keep kernel with the highest version number
latest-N      - Keep kernel with the Nth highest version number
running       - Keep the running kernel
oldest        - Keep kernel with the lowest version number
oldest+N      - Keep kernel with the Nth lowest version number

If no value is specified, no kernel will be purged.

locksfile.path ({configdir}/locks)

The file holding the applied package locks. See the zypper(8) locks, addlock and removelock commands for more details.

locksfile.apply (true)

Whether to apply locks stored in the locksfile file at start.

update.messages.notify (<EMPTY>)

Upon their installation packages may leave an update message file in /var/adm/update-messages. At the end of each commit, zypp may collect those messages and send a notification to the user.

zypp will prepare the update messages according to the selected content format and pipe the content to the specified command.

Format:

single - For each update message invoke the command and send the message.
none   - For each update message invoke the command but don’t use a pipe to send any data. You probably want to pass the message file on the commandline using %P (see Substitutions below).
digest - Single invocation of the command, sending the path names of all update message. One per line.
bulk   - Single invocation of the command, sending the concatenated content of all update messages, separated by Ctrl-L.

Substitutions:

%p     - Package identification (Name-Version-Release.Arch_)
%P     - Full path to the update message file

Valid values:

The value is specified as format | command. An empty value will turn off any notification.

Examples:

single | mail -s "Update message from %p" root
none   | my-send-script -f %P

rpm.install.excludedocs (false)

Don’t install any files which are marked as documentation. See the rpm(8) --excludedocs option for details.

This is often used when building container images to save disk space.

history.logfile (/var/log/zypp/history)

Location of the history log file. The history log contains an abstract of the install actions performed by libzypp and also collects any screen output of packages during their installation, in case yue want to review it.

credentials.global.dir ({configdir}/credentials.d)

Global credentials directory path.

If an URL contains a ?credentials=<filename> parameter, the credentials will be stored and looked for in a file named <filename> in this directory.

credentials.global.file ({configdir}/credentials.cat)

Global credentials catalog file path.

This file may contain a catalog of user credentials which are not stored via the ?credentials=<filename> URL parameter (see credentials.global.dir).

The file is read if it exists, but new credentials are usually stored in the users home directory (~/.zypp/credentials.cat).

arch (<UNSET>)