Zypper locks do not block unwanted "new" patterns and consequent new packages in 20260908

English Applications
1

I started to compose a bug about this when I thought it mainly about locks, but changed my mind to think something else was going on. Code pastes are not entirely in order, but last is last (aborted) transaction. It seems either zypper locking has gone bananas, and/or upgraded patterns have wildly mushroomed to add more patterns than what had been installed, in addition to a huge swarm of packages:

# inxi -S
System:
  Host: ab560 Kernel: 7.0.12-1-default arch: x86_64 bits: 64
  Desktop: KDE Plasma v: ERR-101 Distro: openSUSE Tumbleweed 20260721
# grep -i yreq /etc/zypp/zypp.conf.d/zypplocal.conf
 solver.onlyRequires = true
# zypper ll

#  | Name                                 | Type    | Repository | Comment
---+--------------------------------------+---------+------------+--------
1  | *games*                              | package | (any)      |
2  | *gnome*                              | package | (any)      |
3  | *immodule*                           | package | (any)      |
4  | *lang                                | package | (any)      |
5  | MozillaFirefo*                       | package | (any)      |
6  | busybox*                             | package | (any)      |
7  | cantarel*                            | package | (any)      |
8  | cryptsetu*                           | package | (any)      |
9  | documentatio*                        | pattern | (any)      |
10 | emacs*                               | package | (any)      |
11 | enchant*                             | package | (any)      |
12 | firewal*                             | package | (any)      |
13 | google*fonts                         | package | (any)      |
14 | groff-ful*                           | package | (any)      |
15 | gsetting*                            | package | (any)      |
16 | gtk4*                                | package | (any)      |
17 | hack-font*                           | package | (any)      |
18 | hicolor-icon-theme-branding-openSUS* | package | (any)      |
19 | kde_*                                | pattern | (any)      |
20 | kernel-de*                           | package | (any)      |
21 | kernel-lo*                           | package | (any)      |
22 | libabsl_*                            | package | (any)      |
23 | man-pages-posi*                      | package | (any)      |
24 | metatheme-breeze6-commo*             | package | (any)      |
25 | multimedi*                           | pattern | (any)      |
26 | nftable*                             | package | (any)      |
27 | offic*                               | pattern | (any)      |
28 | pam-manpage*                         | package | (any)      |
29 | pam_pwqual*                          | package | (any)      |
30 | plymout*                             | package | (any)      |
31 | ruby*                                | package | (any)      |
32 | sddm*                                | package | (any)      |
33 | speec*                               | package | (any)      |
34 | sw_managemen*                        | pattern | (any)      |
35 | switche*                             | package | (any)      |
36 | sysconfi*                            | package | (any)      |
37 | sysconfi-netcon*                     | package | (any)      |
38 | urw-base3*                           | package | (any)      |
39 | wicke*                               | package | (any)      |
40 | wireles*                             | package | (any)      |
41 | xf86-input-evde*                     | package | (any)      |
42 | xf86-input-joystic*                  | package | (any)      |
43 | xf86-input-mous*                     | package | (any)      |
44 | xf86-input-synaptic*                 | package | (any)      |
45 | xf86-input-vmmous*                   | package | (any)      |
46 | xf86-input-waco*                     | package | (any)      |
47 | xfsprog*                             | package | (any)      |
48 | xorg-x11-driver-vide*                | package | (any)      |
49 | xorris*                              | package | (any)      |
50 | xscreensave*                         | package | (any)      |

# zypper -v up -d
...
The following 8 NEW patterns are going to be installed:
  documentation      20241218-34.1
  kde_internet       20260830-1.1
  kde_multimedia     20260830-1.1
  kde_utilities_opt  20260830-1.1
  kde_yast           20260830-1.1
  multimedia         20201106-5.3
  office             20170506-3.20
  sw_management      20241218-34.1

989 packages to upgrade, 889 new.
...

Those patterns were before I learned that to lock a pattern zypper needed switch --pattern, and added 80% of those locks to trim new packages down from 889. But, what triggered demand for so many additional patterns?

# rpm -qa | wc -l
1241
# zypper -v dup
...
1122 packages to upgrade, 269 new, 7 to remove.

Package download size:
              |     811.3 MiB  overall package size
    80.1 MiB  |  -  731.2 MiB  already in cache

Download only.

Backend:  classic_rpmtrans --download-only
Continue? [y/n/v/...? shows all options] (y):
#

Expected behavior: keep installation lean/minimalist, free of things I don't use and their attendant updates.
2

You upgrade once a week or so? A few new patterns were included with snapshot 20260830 and likely those escaped your locks?

1 Like
3

As suggested by OP, last dup was 20260721, so I expected a multitude of mass rebuild packages, but not new stuff, particularly 0 new patterns.

4

Another try on a different host, with locks increased from 35 to 37, and all patterns removed, zypper dup still wants to install 223 new files, including what appears to be all of yast*, more qt6*, samba-winbind* & other, 63 pythons, 6 ispells & myspells, 5 perls, more pipewires, 4 gvfs* & 2 audit*. I removed samba*, and dup still wants to add 116 packages, including 3 KDE3*! :frowning:

5

You are long enough around to know zypper dup --no-recommends

From man zypper:

–no-recommends

By default, zypper installs also packages recommended by the requested ones. This option causes the recommended packages to be ignored and only the required ones to be installed.

For this topic already countless other threads exist. If you want a fully tailored system without any additional packages, you need to use at least the basic tools and options provided by zypper and the OS. This includes options like --no-recommends.

6

From man zypp.conf

From OP:

$ ls -Ggh zypplocal.conf
-rw-r--r-- 1 270 Jan 30  2026 zypplocal.conf
$ cat zypplocal.conf
 download.min_download_speed = 20000
 download.max_silent_tries = 8
 commit.downloadMode = DownloadAsNeeded
 solver.focus = Installed
 solver.onlyRequires = true
 solver.upgradeTestcasesToKeep = 0
 multiversion.kernels = latest,latest-1,latest-2,latest-3,oldest,running

I’ve been using this zypplocal.conf apparently since January. /etc/zypp/zypp.conf had been configured this way here since nearly forever. Looks to me like /etc/zypp/zypp.conf.d/*.conf or solver.onlyRequires support broke. This new behavior appears to be from 20260908.

7

In order to avoid the installation of any pattern I include in the file /etc/zypp/locks of all my installations:

type: package
match_type: regex
case_sensitive: on
solvable_name: ^patterns-*
1 Like
8

Third host, gx780, upgrading from 20260802:

<add 10 locks>
# zypper ll | wc -l
47
# rpm -qa | grep pattern
# zypper  -v dup
...
335 packages to upgrade, 153 new. <abort>
...
# df /
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda18       6412585 4869056   1211754  81% /
<add 10 more locks; +864 bytes>
# zypper ll | wc -l
     57
# zypper  -v dup
...
325 packages to upgrade, 60 new, 12 to remove. <proceed>
...
# df /
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda18       6412585 5143854    936956  85% /
# mv /var/log/zypper.log /pub/zypper.logprv
# df /
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda18       6412585 5038815   1041995  83% /

With locks count up by 20 overall, disappointing improvement over host in post #4.

9

Can @moderators move this to Open Chat or Soapbox ( if that still exists ) ?

11

Quoting from man zypp.conf:

   Note: Key-value assignments outside any section are bound to an unnamed section and may not be recognized.

and your zypplocal.conf does not have the [main] token that should mark the beginning of the main section.

1 Like
12

Thank you for noticing!

Why for months it seemed to work as expected remains a pointless question. Only 4 new packages going to 20260912 from 20260806. Solved! :slight_smile:

13

It was a problem, and a solution was provided. I see no provision to officially mark solved in Open Chat, so it should be put back where it came from.

1 Like
14

These forums are for supporting users of openSUSE. The “problem” was not an openSUSE problem, it was intentionally created by the OP breaking the whole concept of the distro. It is not helping users with their install/boot/login. It is confusing users looking for help and even dangerous for their systems if they follow the OP’s experiments hoping it may help them. Hence my request to move it.

15

Tumbleweed permits custom admin confguration little differerent from any other distro. If the issue had manifested coincident with the change, the cause would have been evident. It should have manifested at that time, but it somehow managed to take months, and on multiple installations. From where I sit, that behavior is just as new software bugs typically exhibit.

16

For any who don’t read the factory mailing list, Andrei responded:

That’s Bug 1272534

File dates in that rpm are 04 Sept., mirrors date 08 Sept. So, apparently there had been no requirement for [main] until then, which explains why this change in behavior started hitting mine on the 9th.

17

Yes, that corroborates OrsoBruno’s earlier observation that solver.onlyRequires needed to be under [main], pointing toward the actual cause rather than the locks themselves being broken.

It also shows why heavily customised configurations can make troubleshooting more difficult. Administrators need to take their own solver settings and locks into account when diagnosing unexpected behaviour (and read documentation of course). :wink:

2 Likes
18

Also, the man page for zypp.conf clearly speaks about SECTIONS and gives what can/should be in those SECTIONS starting with [main].

1 Like
19

If the parsing hadn’t been broken when conversion to using zypp.conf.d was made, the oversight omission would have become apparent when or shortly after the config edit was made, not months later. The behavior was typical of a software bug. Few remember everything that happened months or years prior.

1 Like
20

True, which is why it’s a good idea to document any custom configuration changes - that can help with future troubleshooting when the need arises.

21

Which was ages ago, when the move from /etc to /usr/etc was done.

1 Like