zypper dup(s) - rather a lot of update-alternatives warnings...

I’ve been away (from computers) for a short while and missed several TW snapshots, previously that’s not been a problem, but…

A few days ago I performed a zypper dup from 20200515 to 20200609, 10 snapshots skipped and all packages updated due to TW now being built using GCC 10.1

During that update I notice a lot of update-alternatives warnings of the general form:

update-alternatives: warning: forcing reinstallation of alternative *name* because link group *name* is broken

On subsequent snapshots 20200610 and 20200611 there was again a few of these warnings, for example on 20200611:

update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken

My initial thoughts are perhaps “something” has changed in the way update-alternatives are managed and maybe this should have been “corrected” by a post-install script that hasn’t been ran (because of the missing snapshots) ???

Any pointers welcome, as I really don’t know where to go on this one :\

Yes, I saw many such warnings.

I didn’t worry about it.

Warnings are generally only a bit more important than simply informational and rarely mean that anything is broken.
Just skim the warnings and notice if any might relate to anything special you might be doing or have installed.

If you see an error instead of a warning, that’d be something you’d want to take a closer look at unless the system resolves the error on its own.

IMO,
TSU

Thanks guys.

Indeed it is just a warning and all appears OK, however…

I do believe there is something amiss, as this warning appears to be issued multiple times for the same package. Taking the example of sddm, if I look through “var/log/zypp/history” this warning has been issued on at least eight separate occasions during previous runs of “zypper dup”

paul@Orion-15:~> su -
Password: 
Orion-15:~ # cd /var/log/zypp
Orion-15:/var/log/zypp # grep -i 'sddm because link group' history
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
# update-alternatives: warning: forcing reinstallation of alternative /usr/lib/X11/displaymanagers/sddm because link group default-displaymanager is broken
Orion-15:/var/log/zypp # exit
logout
paul@Orion-15:~>

So, to my way of thinking, either the link group is “broken” and forcing “reinstallation of alternative…” is not “fixing” it. Or, the link group is not “broken”, in which case the warning is bogus.

Either way, it looks like the package manager is misbehaving… Bug report perhaps would be in order?

The package manager is fine. But there may well be a poorly designed script being called by that particular package.

OK, understood, but it’s not just that package…

A “grep” through var/log/zypp/history for ‘forcing reinstallation of alternative’ results in a large number of packages, many multiple times…

I’d obviously not noticed this before, but then again I don’t normally watch the progress of zypper dup once I’ve started it, just let it do it’s thing and run “rpmconfigcheck” afterwards to see if any configuration files need attention.

This error appears fairly clear to me… Just requires a passing familiarity with the alternatives system.
Bottom line is

  • This kind of error indeed will not cause anything to be non-functional. Only means that if you tried to use alternatives to modify, it may not work.
  • Although the fix likely will be simple, with close inspection it might be as simple as a typo. If someone introduced something more extensive, only then maybe the problem might be more extensive. I wouldn’t expect casual Users to fix this. Better to just report to https://bugzilla.opensuse.org

TSU

https://bugzilla.opensuse.org/show_bug.cgi?id=1172896

Thanks for investigating and reporting :slight_smile:

Yes, I often see that – which is why I tend to not take it seriously.

I don’t see that as a problem with the package manager. Perhaps its a bug in the alternatives system. Or perhaps it is a feature, rather than a bug.

I have not looked closely at the alternatives system. If the database records the inode of the various alternatives, then updating any package would be seen as a breakage. And that could be intended as part of the design. That is, it could be that by design a group should be reconfigured if any part is updated.

What about /var/log/alternatives.log?

There are two types of entries:

update-alternatives 2020-06-10 13:56:18: run with --install /usr/lib/gst-install-plugins-helper gst-install-plugins-helper /usr/lib/pk-gstreamer-install 10
update-alternatives 2020-06-10 13:56:18: auto-repair link group gst-install-plugins-helper

update-alternatives 2020-06-11 21:18:59: run with --install /usr/bin/nokogiri nokogiri /usr/bin/nokogiri.ruby2.7-1.10.9 11009
update-alternatives 2020-06-11 21:18:59: link group nokogiri updated to point to /usr/bin/nokogiri.ruby2.7-1.10.9

Is this a feature?

There’s a few other recurring messages (wrong permissions, wrong missing capabilities). If they are wrong, probably the previous package version set that way I suppose? Most, if not all, warnings I recall don’t look like real warnings, it’s just noise.

I’m pretty sure that the permissions messages are a feature. The installed package is set for restrictive permissions (high security), but is them modified in accordance with rules in “/etc/security”.

There’s a bug report (Bug 1172896) on the alternatives messages. The reporter seems to have analyzed what is happening.

Apparently, it is a dog fight between people who want symlinks to be relative and people who want symlinks to be absolute. There was a recent change in Tumbleweed so that now most installed symlinks are relative. And apparently “update-alternatives” doesn’t like that and is changing them back to absolute links.

Thanks for the context. Still I see those messages as merely informational. System is operating as configured. A quieter zypper output would be nicer. I’ll think about opening a bug report.

I think folks involved in update-alternatives should be coherent and come up with a consistent solution. Everybody out there is refactoring their software. Even systemd is pretty nice now. But update-alternatives creates lots of noise.