On Fri 2022-05-20, Hagen Buliwyf wrote:
However working in IT for more than thirty years now there is one rule which i consider very important:
An update must not break a working system.
Agreed. From a user perspective that is key. (Or at least, "an update must not break a commonly configured system" or "...not easily / without ample notification...").
Before that update every system (using NetworkManager) had installed NetworkManager with wifi-functionality (even the systems setup with --no-recommends). Therefore an update which removed that functionality without notice carried the risk to break at least some systems.
Maybe a better mechanism to advise of such situations *before* the user is in troubles can be part of the solution?
I spent some of my time watching various German openSUSE forums and I can see that "incidents" like the one discussed here (or the split of the bluez package a few weeks ago)
Ah, that one? I did fall into that trap myself and wasn't too happy. And Simon Lees wrote:
Recommends really means "The maintainer thinks you really should have this unless your use case has a very good reason not to". So in most cases --no-recommends probably isn't the best starting point for end users even experienced ones.
I'm not convinced. Without using --no-recommends by default I found my system was getting more and more bloated over time (and even with that). So I just tried `zypper -v up --recommends` on my notebook and ... <drumroll> ... After the operation, additional 1,8 GiB will be used. bringing in things like brltty* git-cvs gtk2-engine-hcengine gtk2-immodule-amharic gtk2-immodule-inuktitut gtk2-immodule-thai gtk2-immodule-tigrigna gtk2-immodule-vietnamese gtk3-immodule-amharic gtk3-immodule-inuktitut gtk3-immodule-thai gtk3-immodule-tigrigna gtk3-immodule-vietnamese icewm* kernel-firmware-chelsio kernel-firmware-qlogic (and many others) mariadb* xscreensaver* Gerald