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.

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.

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".

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.

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

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

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.

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.

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}.

Default signature checking of repo metadata and downloaded rpm packages.

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.:

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.

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.

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.

This option should be used on a case by case basis, enabled via command line options or switches the applications offer. Changing the global default on a system where unattended actions are performed, may easily damage your system.

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

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).

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.

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

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

Format:

Substitutions:

Valid values:

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

Examples:

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

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

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).