zypper locks - unexpected influence over version selection during package install

[pfee]

Experimenting with zypper locks on packages not yet installed, I find they lock out installation of the specified version, rather than encourage it. Is this intentional?

For example (output trimmed for brevity):

$ zypper se -s glibc-profile
S | Name                | Type    | Version          | Arch   | Repository
--+---------------------+---------+------------------+--------+-------------------------------------------------------------
  | glibc-profile       | package | 2.31-150300.63.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
  | glibc-profile       | package | 2.31-150300.58.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
  | glibc-profile       | package | 2.31-150300.52.2 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
  | glibc-profile       | package | 2.31-150300.46.1 | x86_64 | Main Repository
$ sudo zypper al glibc-profile=2.31-150300.63.1
$ sudo zypper in glibc-profile
$ zypper se -s glibc-profile
S  | Name                | Type    | Version          | Arch   | Repository
---+---------------------+---------+------------------+--------+-------------------------------------------------------------
vl | glibc-profile       | package | 2.31-150300.63.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | glibc-profile       | package | 2.31-150300.58.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
v  | glibc-profile       | package | 2.31-150300.52.2 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
v  | glibc-profile       | package | 2.31-150300.46.1 | x86_64 | Main Repository

Above, the lock has prevented version 63.1 being installed, rather than encouraging it. This seems the opposite of what one would want. If I want to pre-select installation of a specified version by applying locks before installation, I can instead lock out every other version.

$ sudo zypper al glibc-profile!=2.31-150300.58.1
$ zypper se -s glibc-profile
S  | Name                | Type    | Version          | Arch   | Repository
---+---------------------+---------+------------------+--------+-------------------------------------------------------------
 l | glibc-profile       | package | 2.31-150300.63.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
   | glibc-profile       | package | 2.31-150300.58.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
 l | glibc-profile       | package | 2.31-150300.52.2 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
 l | glibc-profile       | package | 2.31-150300.46.1 | x86_64 | Main Repository
$ sudo zypper in glibc-profile
$ zypper se -s glibc-profile
S  | Name                | Type    | Version          | Arch   | Repository
---+---------------------+---------+------------------+--------+-------------------------------------------------------------
vl | glibc-profile       | package | 2.31-150300.63.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | glibc-profile       | package | 2.31-150300.58.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
vl | glibc-profile       | package | 2.31-150300.52.2 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
vl | glibc-profile       | package | 2.31-150300.46.1 | x86_64 | Main Repository

Is it expected that version specific locks can lock in existing installations, but when applied to versions not yet installed, they block installation?

[mlandres]

Yes. A lock is a query and it prevents matching package to change their state. Installed ones stay installed, absent ones stay absent.

[pfee]

Thanks for the feedback, although a surprise (to me at least), it clarifies the rationale behind how zypper locks operate. Therefore I'm closing this ticket.