Zypper install specific major version without specifying the minor version

opensusepackage-managementzypper

I am writing a script that installs some packages and does some configuration work. I want the script to install a specific major version of a package, but I do not care which minor version of the package it is.

More to the point, I want it to install the latest 2.y.z release of the package, but not 1.y.z or 3.y.z (or any other major version number).

I have tried (without success)

zypper install 'mypackage=2'
zypper install 'mypackage>1<3'
zypper install 'mypackage>1' 'mypackage<3'
zypper install 'mypackage>=2.0.0' 'mypackage<3.0.0'

The last one seems promising, because then zypper complains:

'mypackage>=2.0.0' not found in package names. Trying capabilities. No
provider of 'mypackage >= 2.0.0' found.

However, after that message, it still proceeds with installing mypackage-1.5.0, because that satisfies the second package-edition specified.

Best Answer

Better

At first I experimented with SailorCire's answer here and came up with an improved version:

zypper search -t package -x -s PACKAGE | grep " MIN_NUM" | cut -d '|' -f 4 | tr -d '[:space:], then you can pipe it into zypper install by doing zypper install PACKAGE followed by backticks-surrounded command above.

For example, this will install php7-pear 1.*:

zypper -n in --details php7-pear-`zypper search -t package -x -s php7-pear | grep " 1." | cut -d '|' -f 4 | tr -d '[:space:]'`

Best

But then I came up with a better solution. Rather than target a specific version with hacks like this, we can exclude versions without hacks using zypper addlock with version constraints.

So, what OP wants is actually this:

zypper addlock "mypackage < 2"
zypper addlock "mypackage >= 3"

These will prevent mypackage installs with versions <2 or >=3.

Related Solutions

Bash – How to use zypper in bash scripts for someone coming from apt-get

In general, you should use --non-interactive mode, in shortcut -n, when running zypper non-interactively:

zypper -n install curl

That might seem confusing for someone coming from apt-get install -y curl. Some zypper sub-commands also support a command-specific -y/--no-confirm option as an alias for -n/--non-interactive, but not all sub-commands do. As the install command does implement that, this command is equivalent to the above:

zypper install -y curl

Note that the -y must come after install, while the global -n option comes before the subcommand (zypper install -n means something different; read the man page for that).

[Edit] The section below is no longer accurate, but is retained for historical reference. Current zypper supports the --gpg-auto-import-keys option to automatically import and trust the gpg keys associated with a new repository.

According to documentation there's no way how to accept a GPG key without interactive mode:

a new key can be trusted or imported in the interactive mode only

Even with --no-gpgp-checks the GPG key will be rejected.

A workaround for scripts is to use pipe and echo:

zypper addrepo http://repo.example.org my_name | echo 'a'

Where does zypper install the repository or package signing keys

On the openSuSE forums, user Robi Listas gave the start of an answer which I finished. Here is the summary:

Zypper does not expose the location of the keys, but the repository key files on openSuSE are in /var/cache/zypp/raw/*/repodata where * is the alias name of a repository from the list you can get through zypper repos.

I wrote a small bash repomd_test.sh script based on a script by Tojaj that you can call like this for each repodata directory:

for d in /var/cache/zypp/raw/*/repodata; do ~/repomd_test.sh $d; done

Each of those directories has three files:

repomd.xml signed repository file (this is XML)
repomd.xml.asc ASCII "armor" signature of repomd.xml
repomd.xml.key ASCII public key used to create the repomd.xml.asc signature

The script creates a temporary keyring directory for GnuPG.

Then for the repodata, it adds the repomd.xml.key to the keyring, then verifies that the repomd.xml indeed corresponds to the repomd.xml.asc signature and prints the fingerprint and meta information (like expiration).