19.05.22 13:38 - Dominique Leuenberger / DimStar:

On Thu, 2022-05-19 at 11:00 +0000, Dominique Leuenberger wrote:

...

Packages changed: NetworkManager (1.36.4 -> 1.38.0)

=== Details ===

==== NetworkManager ==== Version update (1.36.4 -> 1.38.0) Subpackages: NetworkManager-lang NetworkManager-pppoe libnm0 typelib-1_0-NM-1_0

- Recommend NetworkNanager-wifi from the main package: after the split, there is currently nothing pulling in NM-wifi. Preferably this would happen based on wifi chips prsence, but that is not yet done (boo#1199550). - Modify NetworkManager.spec: Split into a few small subpackages (bsc#1198128).

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

Users that decide to 'disable recommends' need to be extra careful here: the NetworkManager-wifi plugin is only recommended (NM on wired does not need the plugin).

Always keep in mind: disabling recommends means you claim you know better than others.

No, I don't claim that. However the bandwidth available to me does not allow me (neither by cost nor time) to download ~10.000 packages a year which I will never need nor use.

so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

This is not about installing this is about the fact that an "cosmetic" update removed (vital) functionality which had been deliberately installed by the user.

Cheers, Dominique

19.05.22 15:29 - Stefan Brüns:

On Donnerstag, 19. Mai 2022 15:18:56 CEST Hagen Buliwyf wrote:

...

19.05.22 13:38 - Dominique Leuenberger / DimStar:

However the bandwidth available to me does not allow me (neither by cost nor time) to download ~10.000 packages a year which I will never need nor use.

...

so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

This is not about installing this is about the fact that an "cosmetic" update removed (vital) functionality which had been deliberately installed by the user.

There are no "cosmetic" updates on Tumbleweed.

You are crying out loud

No, I'm not "crying out loud". I'm just pointing out that there is an update that breaks working systems. To me that was not a real problem (the bluez package had been messed up the same way a few weeks ago) except that i had to spend quite a while searching a LAN port.

because a default install installs too much, but are also blaming people for making the distribution more modular, so features not required by everyone are optional? Spot the error?

Which error? That on one hand the distribution is made more modular while on the other hand people who make use of that modularity are finger-pointed?

Regards,

Stefan

PS: I doubt

Well, it is up to you whether you believe me or not. I do not really care ... the bandwidth argument. I have 16Mbps, and that is sure more than

enough for a couple of machines with different architectures, and doing Homeoffice. And when you use zypper in "download only" mode, time also becomes a non-issue (download first, install whenever suitable).

Hi On 5/19/22 22:48, Hagen Buliwyf wrote:

19.05.22 13:38 - Dominique Leuenberger / DimStar:

...

On Thu, 2022-05-19 at 11:00 +0000, Dominique Leuenberger wrote:

...

Packages changed:    NetworkManager (1.36.4 -> 1.38.0)

=== Details ===

==== NetworkManager ==== Version update (1.36.4 -> 1.38.0) Subpackages: NetworkManager-lang NetworkManager-pppoe libnm0 typelib-1_0-NM-1_0

- Recommend NetworkNanager-wifi from the main package: after the    split, there is currently nothing pulling in NM-wifi. Preferably    this would happen based on wifi chips prsence, but that is not    yet done (boo#1199550). - Modify NetworkManager.spec: Split into a few small subpackages    (bsc#1198128).

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

Users that decide to 'disable recommends' need to be extra careful here: the NetworkManager-wifi plugin is only recommended (NM on wired does not need the plugin).

Always keep in mind: disabling recommends means you claim you know better than others.

No, I don't claim that.

However the bandwidth available to me does not allow me (neither by cost nor time) to download ~10.000 packages a year which I will never need nor use.

...

so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

This is not about installing this is about the fact that an "cosmetic" update removed (vital) functionality which had been deliberately installed by the user.

The problem is while this is vital functionality for you it isn't vital functionality for everyone think things like container workloads that previously probably used wicked. This is why it makes sense for packages like this to be recommends rather then requires. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Thursday 2022-05-19 13:38, Dominique Leuenberger / DimStar wrote:

On Thu, 2022-05-19 at 11:00 +0000, Dominique Leuenberger wrote:

...

- Recommend NetworkNanager-wifi from the main package: after the split, there is currently nothing pulling in NM-wifi. Preferably this would happen based on wifi chips prsence, but that is not yet done (boo#1199550). - Modify NetworkManager.spec: Split into a few small subpackages (bsc#1198128).

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

As for NetworkManager-wifi.rpm, it requires libglib and wpa_supplicant, both of which are already needed by NetworkManager.rpm. So separting *that particular* component was a rather questionable move.

On 19.05.2022 19:13, Dominique Leuenberger / DimStar wrote:

On Thu, 2022-05-19 at 18:05 +0200, Jan Engelhardt wrote:

...

On Thursday 2022-05-19 13:38, Dominique Leuenberger / DimStar wrote:

...

On Thu, 2022-05-19 at 11:00 +0000, Dominique Leuenberger wrote:

...

- Recommend NetworkNanager-wifi from the main package: after the split, there is currently nothing pulling in NM-wifi. Preferably this would happen based on wifi chips prsence, but that is not yet done (boo#1199550). - Modify NetworkManager.spec: Split into a few small subpackages (bsc#1198128).

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

As for NetworkManager-wifi.rpm, it requires libglib and wpa_supplicant, both of which are already needed by NetworkManager.rpm. So separting *that particular* component was a rather questionable move.

It actually rather looks like the dep on wpa_supplicant was missed to move to -wifi

wpa_supplicant is also used for Ethernet authentication with 802.1x.

On Fri, May 20, 2022 at 6:40 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:

Am 19.05.22 um 13:38 schrieb Dominique Leuenberger / DimStar:

...

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

Users that decide to 'disable recommends' need to be extra careful here: the NetworkManager-wifi plugin is only recommended (NM on wired does not need the plugin).

Always keep in mind: disabling recommends means you claim you know better than others. so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

There is a section in our Wiki page about Package dependencies [1]:

...

The dependency resolution (installing *both* new packages) is done by YaST with the split-alias mentioned in Provides: of pac-devel.

[...]

During an update, the aformentioned split-alias tag is important. YaST only updates already installed packages, in this case only the main package. Without the split-alias, this would remove files needed for development which were part of the old main package but are not in the new main package.

Is that still recommended? There is a warning:

...

Split-alias tags are used by YaST only, RPM never sees them.

How about zypper though?

Aaron

[1] <https://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_into_two>

That documentation is more or less obsolete. If you're splitting packages, you should have Obsoletes: on each package being split out so that libsolv considers them upgrade candidates. You can also use Recommends from the old package to have the two others pulled in by default. But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead. I think it's not reasonable to expect it to be missing for a desktop environment by default. -- 真実はいつも一つ！/ Always, there's only one truth!

On 21.05.2022 02:56, Neal Gompa wrote:

On Fri, May 20, 2022 at 6:40 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:

...

Am 19.05.22 um 13:38 schrieb Dominique Leuenberger / DimStar:

...

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

Users that decide to 'disable recommends' need to be extra careful here: the NetworkManager-wifi plugin is only recommended (NM on wired does not need the plugin).

Always keep in mind: disabling recommends means you claim you know better than others. so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

There is a section in our Wiki page about Package dependencies [1]:

...

The dependency resolution (installing *both* new packages) is done by YaST with the split-alias mentioned in Provides: of pac-devel.

[...]

During an update, the aformentioned split-alias tag is important. YaST only updates already installed packages, in this case only the main package. Without the split-alias, this would remove files needed for development which were part of the old main package but are not in the new main package.

Is that still recommended? There is a warning:

...

Split-alias tags are used by YaST only, RPM never sees them.

How about zypper though?

Aaron

[1] <https://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_into_two>

That documentation is more or less obsolete.

You forgot to explain how to make YaST/zypper/rpm to install NetworkManager-wifi on update from previous release before -wifi split. The part that Aaron mentioned is most certainly not obsolete and actually works. tw:~ # rpm -qil foo Name : foo Version : 1 Release : 1 Architecture: noarch Install Date: Sat May 21 08:09:33 2022 Group : Unspecified Size : 0 License : GPL Signature : (none) Source RPM : foo-1-1.src.rpm Build Date : Sat May 21 08:03:53 2022 Build Host : bor-Latitude-E5450 Summary : testing subpackage split Description : Testing subpackage split Distribution: (none) /tmp/bar /tmp/foo tw:~ # zypper in -r local foo Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be upgraded: foo The following NEW package is going to be installed: foo-bar 1 package to upgrade, 1 new. Overall download size: 11.7 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y): Retrieving package foo-1-2.noarch (1/2), 5.8 KiB ( 0 B unpacked) Retrieving package foo-bar-1-2.noarch (2/2), 5.8 KiB ( 0 B unpacked) Checking for file conflicts: .............................................[done] (1/2) Installing: foo-1-2.noarch .........................................[done] (2/2) Installing: foo-bar-1-2.noarch .....................................[done] tw:~ # rpm -ql foo /tmp/foo tw:~ # rpm -ql --provides foo-bar foo-bar = 1-2 foo:/tmp/bar /tmp/bar tw:~ #

If you're splitting packages, you should have Obsoletes: on each package being split out so that libsolv considers them upgrade candidates.

No, it does not work. tw:~ # zypper info --obsoletes foo foo-bar Loading repository data... Reading installed packages... Information for package foo: ---------------------------- Repository : local Name : foo Version : 1-2 Arch : noarch Vendor : Installed Size : 0 B Installed : Yes Status : out-of-date (version 1-1 installed) Source package : foo-1-2.src Summary : testing subpackage split Description : Testing subpackage split Obsoletes : foo < 1-2 Information for package foo-bar: -------------------------------- Repository : local Name : foo-bar Version : 1-2 Arch : noarch Vendor : Installed Size : 0 B Installed : No Status : not installed Source package : foo-1-2.src Summary : Package split from foo Description : Package split from foo Obsoletes : foo < 1-2 tw:~ # zypper in -r local foo Loading repository data... Reading installed packages... Resolving package dependencies... The following package is going to be upgraded: foo 1 package to upgrade. Overall download size: 5.9 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y):

You can also use Recommends from the old package to have the two others pulled in by default.

Have you tried to actually read this thread?

But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead.

It is not the question here. The question is how to make sure NetworkManager-wifi is installed after update from package version before split. You cannot assume everyone having NetworkManager also has desktop pattern. So split-alias mentioned by Aaron actually work. My only complain is that it does not work with plain rpm, but then it is not clear how it can be made to work in the first place.

On Sat, May 21, 2022 at 8:00 AM Simon Lees <sflees@suse.de> wrote:

On 5/21/22 14:59, Andrei Borzenkov wrote:

...

On 21.05.2022 02:56, Neal Gompa wrote:

...

On Fri, May 20, 2022 at 6:40 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:

...

Am 19.05.22 um 13:38 schrieb Dominique Leuenberger / DimStar:

...

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

Users that decide to 'disable recommends' need to be extra careful here: the NetworkManager-wifi plugin is only recommended (NM on wired does not need the plugin).

Always keep in mind: disabling recommends means you claim you know better than others. so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

There is a section in our Wiki page about Package dependencies [1]:

...

The dependency resolution (installing *both* new packages) is done by YaST with the split-alias mentioned in Provides: of pac-devel.

[...]

During an update, the aformentioned split-alias tag is important. YaST only updates already installed packages, in this case only the main package. Without the split-alias, this would remove files needed for development which were part of the old main package but are not in the new main package.

Is that still recommended? There is a warning:

...

Split-alias tags are used by YaST only, RPM never sees them.

How about zypper though?

Aaron

[1] <https://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_into_two>

That documentation is more or less obsolete.

...

You can also use Recommends from the old package to have the two others pulled in by default.

Have you tried to actually read this thread?

...

But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead.

It is not the question here. The question is how to make sure NetworkManager-wifi is installed after update from package version before split. You cannot assume everyone having NetworkManager also has desktop pattern.

Especially given the desktop patterns don't work with recommends atm boo#1028028 (MicroOS Desktop might have made it better for Gnome but I haven't compared that to the other desktop patterns in a fair while).

It should not be a weak dependency in the pattern. -- 真実はいつも一つ！/ Always, there's only one truth!

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

On Tue, 24 May 2022 10:51:48 +0200, Simon Lees wrote:

Thankyou for reminding me, the "Language" part is something we should try to address better for ALP so you can specify the language or languages you'd like and just get immodules and translations for that language rather then the all or nothing approach we have now.

Not really, we already have per-language (locale) package choices since decades ago. e.g. fcitx5-mozc package contains the following: Provides: locale(fcitx5:ja) so that it'll be automatically installed when fcitx5 input framework is installed in Japanese locale. Admittedly, many packages still miss it and we should cover it better, though. Also, the handling for an optional package is missing; that is, a package that not everybody likes (so no need for the default installation) but is still specific to some language. thanks, Takashi

Thankyou for reminding me, the "Language" part is something we should try to address better for ALP so you can specify the language or languages you'd like and just get immodules and translations for that language rather then the all or nothing approach we have now.

That "all or nothing" approach is particularly evil when something requires some odds&ends from within the LaTeX-verse... Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

On 5/25/22 20:21, Gerald Pfeifer wrote:

On Tue 2022-05-24, Simon Lees wrote:

...

Thankyou for reminding me, the "Language" part is something we should try to address better for ALP so you can specify the language or languages you'd like and just get immodules and translations for that language rather then the all or nothing approach we have now.

Thank you, Simon!

When you say ALP, do I assume correctly this is something to tackle in Tumbleweed first, so no timing dependency, merely an area of focus?

Yeah, from further research a bunch of the work has already been done and there are just various places that still need hooking together. If this becomes a feature that PM's believe is important for ALP then likely we will get some resources to finish addressing the issue in both Tumbleweed and ALP whereas otherwise it will probably end up waiting for someone in the community to have time and notice. (If someone in the community would like to start work on this anyway its some pretty straight forward packaging that would be well suited to a new comer (or anyone else) and I can give you some info to help you get started. I am traveling in the next 24hrs so I don't have time to dump the info here right now. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Tue, 24 May 2022 11:16:03 +0200, Alois Wohlschlager wrote:

This entity can't be decoded. eof-block-branches Here is original data.

On Montag, 23. Mai 2022 17:57:06 CEST Gerald Pfeifer wrote:

...

kernel-firmware-chelsio kernel-firmware-qlogic (and many others)

Given that the firmware packages already have Supplements: namespace:modalias(...) in place, I wonder why kernel-firmware is still recommended by kernel-default.

It's all about "better than sorry-to-break". The major concern was the hotplug network device that requires a (new) firmware and if that's the only available network -- then you'll lose the possibility for the whole updates. I myself am very much for dropping this Recommends from kernel package. IMO, this could be moved to other ways, e.g. patterns, in addition to the Supplements-based installation with hardware detection. But it hasn't happened, so far, unfortunately -- because it cannot work in 100% safe way. Takashi

* Martin Wilck <mwilck@suse.com> [05-23-22 12:53]:

On Sat, 2022-05-21 at 21:30 +0930, Simon Lees wrote:

...

But in trying to answer that question I don't think you really can. Recommends really means "The maintainer thinks you really should have this unless your use case has a very good reason not to".

People keep saying this on this ML, but I don't buy it. First of all, it's different from the natural language meaning of "Recommends". It'd rather be like "VeryStronglyRecommends:". Second, not every maintainer uses it like this.

Setting solver.onlyRequires = true is the first thing I usually do on openSUSE. I am aware that it sometimes causes traps, but I prefer thatn over the bloat that results if I don't.

I believe that we have better instruments than "Recommends" these days, in particular booleans. In the example at hand, we could create a pseudo-package by the name of, say, "system-requires-wifi". Yast would install this package automatically during system setup if Wifi hardware was deteced. Then Networkmanager could have a dependency like this:

Requires: (NetworkManager-wifi = %{version} if system-requires-wifi)

I very strongly agree with this approach. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

On Mon, 2022-05-23 at 21:22 +0300, Andrei Borzenkov wrote:

On 23.05.2022 19:50, Martin Wilck wrote:

...

I believe that we have better instruments than "Recommends" these days, in particular booleans. In the example at hand, we could create a pseudo-package by the name of, say, "system-requires-wifi". Yast would install this package automatically during system setup if Wifi hardware was deteced. Then Networkmanager could have a dependency like this:

Requires: (NetworkManager-wifi = %{version} if system-requires- wifi)

a) If YaST can detect wifi during setup YaST can also install NetworkManager-wifi. Yet another dummy package makes no sense.

It's more flexible. Even if the wifi hw wasn't present during installation, or if the user doesn't use YaST, she could install "system-requires-wifi" later. Or uninstall it if she decides she isn't going to use wifi any more.

b) how exactly is it going to help those users who got broken system during simple update?

By making sure Networkmanager wouldn't be installed without Networkmanager-wifi? That was the idea at least. If you think it wouldn't work, please explain. Martin

On Tue, 2022-05-24 at 10:21 +0300, Andrei Borzenkov wrote:

...

Even if the wifi hw wasn't present during installation, or if the user doesn't use YaST, she could install "NetworkManager-wifi" later. Or uninstall it if she decides she isn't going to use wifi any more.

Again - why is indirection via an additional package needed?

Because "system-requires-wifi" is independent of NM. It would apply likewise to wicked or any other network-related software. It describes an abstract property of the system, not a concrete package.

...

...

b) how exactly is it going to help those users who got broken system during simple update?

By making sure Networkmanager wouldn't be installed without Networkmanager-wifi? That was the idea at least. If you think it wouldn't work, please explain.

As usual on openSUSE lists, the original problem was long forgotten.

It's a common thing to happen on mailing lists in general. But in this case, I didn't forget.

It is not about how to auto-select NetworkManager-wifi during *new* system installation (this is a different, although related, problem).

In the past the NetworkManager package included WiFi support. Now WiFi support was split into the separate package recommended by NetworkManager. If a user configured system to not install recommends by default, on update the user will not have NetworkManager-wifi installed and WiFi stops working. For a lot of users this is equivalent to bricking their system (they cannot as much as post the question anymore).

All understood.

In this thread was a suggestion how this can be fixed - by using split-alias which is documented on our wiki and actually seems to work (at least in my limited testing) and costs a single line in the spec file. But given the attitude "this is a self-inflicted wound" apparently nobody is interested in making this more friendly for end-users. Which is not surprising at all ...

Not sure why you're ranting against my post. I haven't said anything against the split-alias approach [*]. I was just suggesting a more general way to specify complex requirements. It's obviously too late now for the NM-wifi issue. We're discussing future improvements. Martin [1] Although I agree with other posters in this thread that it isn't ideal to use a dependency type (split-alias) that only zypper understands.

On Mon, 23 May 2022, Martin Wilck wrote:

On Sat, 2022-05-21 at 21:30 +0930, Simon Lees wrote:

...

But in trying to answer that question I don't think you really can. Recommends really means "The maintainer thinks you really should have this unless your use case has a very good reason not to".

People keep saying this on this ML, but I don't buy it. First of all, it's different from the natural language meaning of "Recommends". It'd rather be like "VeryStronglyRecommends:". Second, not every maintainer uses it like this.

Setting solver.onlyRequires = true is the first thing I usually do on openSUSE. I am aware that it sometimes causes traps, but I prefer thatn over the bloat that results if I don't.

I believe that we have better instruments than "Recommends" these days, in particular booleans. In the example at hand, we could create a pseudo-package by the name of, say, "system-requires-wifi". Yast would install this package automatically during system setup if Wifi hardware was deteced. Then Networkmanager could have a dependency like this:

Requires: (NetworkManager-wifi = %{version} if system-requires-wifi)

I disagree - system configuration should not be done via rpm requires (or even recommends). It might be good to do the reverse, have NetworkManager-wifi provide system-wifi-services or something like that. And then have the system configuration tool make sure to install a wifi provider if the user enabled Wifi. Now - this doesn't help future package splits since obviously the system configuration tool would need to know beforehand. But Tumbleweeds way is also really not for un-audited dups since by definition a dup is a system configuration (as opposed to, say zypper update -t patch which is what I do on Leap). So conceptually every 'dup' requires system re-configuration (and in the current way that's manual, even more so with no-recommends which doesn't seem to get any serious testing). Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On 24.05.22 08:57, Martin Wilck wrote:

The basic idea is that the user can specify what she needs, in a way the package management system can understand, even though it's orthogonal to ordinary packages. In this case, she'd say she needs "wifi", and thus any package for networking support would pull in all related packages for making wifi functional, documentation packages would pull in wifi-specific pages, etc. Likewise, the user could determine that she's using KDE, and have tools pull in their KDE UI rather than a GTK based UI if there's a choice. Or she could say that she wants language support for Italian, Spanish, and Sanskrit, and have packages pull in the related i18n, but no other.

I like that. And that's what patterns already do, isn't it? So maybe more fine grained patterns are a doable solution? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

Hello, On 2022-05-24 10:55, Simon Lees wrote:

Patterns are just meta packages with extra, if we wanted a user to be able to select "Wifi" from the advanced software selection in the installer then having a "wifi" pattern require it would be the easiest way. If we think that yast or maybe even zypper should be able to figure this out on its own based off the fact there is a wifi adapter present a pattern might be overkill given it carries extra metadata + an icon.

I think patterns are needed in any case to have one single generic method to let the user configure what software is wanted. If there are hardcoded package install automatisms outside of RPM it works again against the user because the user cannot choose to not get that software installed. In this particular example think about a computer with a WiFi adapter but for some reason the user does not want to use WiFi or must not use WiFi (e.g. it may be forbidden to use WiFi on that computer because of whatever restrictions in the environment where that computer is used) - then it could become rather complicated for the user to somehow disable the automatism by some rather low-level hacking. In contrast if a WiFi pattern was used "in between" the automatism may only request to install this pattern but the user could simply "taboo" this one pattern instead of "tabooing" a list of various individual packages which may change over time. Assume there is a computer without WiFi adapter but for some reason the user does want to get WiFi software installed right now. If a WiFi pattern exists the user could simply install this single pattern instead of installing a list of various individual packages which may change over time. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)

Hello, On 2022-05-24 13:35, Simon Lees wrote:

On 5/24/22 20:41, Johannes Meixner wrote:

...

In contrast if a WiFi pattern was used "in between" the automatism may only request to install this pattern but the user could simply "taboo" this one pattern instead of "tabooing" a list of various individual packages which may change over time.

It doesn't work like this as patterns only Require or Recommend other software they don't Provide anything, so all you achieve by "tabooing" a pattern is that pattern won't be installed, if I had a wifi pattern "tabooed" it would not prevent NetworkManager-Wifi from being installed.

Sigh :-( The more I learn about package dependencies the more I come to the conclusion that it could be impossible to use them to let the user choose what software is wanted or unwanted. Perhaps only hard dependencies do actually work but weak dependencies are in the end a dead end? Perhaps weak dependencies do not actually solve something but only mitigate/hide certain issues for average users while causing other problems for other users? Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nuernberg)

Citeren Marcus Meissner <meissner@suse.de>:

Hi,

The main problem with this transition that I had was that "zypper dup" updated NetworkManager first which restarted itself immediately, which lost the wifi network.

NetworkManager-wifi would probably have been the next package to update, but my Laptop had lost the network already.

Happens if you do "download on demand" strategy, like everyone with small disks.

In my case, 'zypper dup' downloads all packages first, yet NetworkManager-wifi was not downloaded and connection was lost after all downloaded packages were installed. So somehow the mechanism to install the recommended package failed for me, despite the default '/etc/zypp/zypp.conf' file.

Citeren Andrei Borzenkov <arvidjaar@gmail.com>:

On 24.05.2022 17:32, Arjen de Korte wrote:

...

Citeren Marcus Meissner <meissner@suse.de>: In my case, 'zypper dup' downloads all packages first, yet NetworkManager-wifi was not downloaded and connection was lost after all downloaded packages were installed. So somehow the mechanism to install the recommended package failed for me, despite the default '/etc/zypp/zypp.conf' file.

And exact date and TW snapshot number when you updated?

That would be Tumbleweed snapshot 20220518, installed within a few hours of the release announcement (2022-05-19).

On 24.05.2022 18:14, Hagen Buliwyf wrote:

24.05.22 16:32 - Arjen de Korte:

...

Citeren Marcus Meissner <meissner@suse.de>:

...

Hi,

The main problem with this transition that I had was that "zypper dup" updated NetworkManager first which restarted itself immediately, which lost the wifi network.

NetworkManager-wifi would probably have been the next package to update, but my Laptop had lost the network already.

Happens if you do "download on demand" strategy, like everyone with small disks.

In my case, 'zypper dup' downloads all packages first, yet NetworkManager-wifi was not downloaded and connection was lost after all downloaded packages were installed. So somehow the mechanism to install the recommended package failed for me, despite the default '/etc/zypp/zypp.conf' file.

'zypper dup' will not download newly added recommends. Even if

Of course it will. But recommend for -wifi was added several TW snapshots after package split.

On 24.05.2022 18:34, Arjen de Korte wrote:

Citeren Andrei Borzenkov <arvidjaar@gmail.com>:

...

On 24.05.2022 18:14, Hagen Buliwyf wrote:

...

24.05.22 16:32 - Arjen de Korte:

...

Citeren Marcus Meissner <meissner@suse.de>:

...

Hi,

The main problem with this transition that I had was that "zypper dup" updated NetworkManager first which restarted itself immediately, which lost the wifi network.

NetworkManager-wifi would probably have been the next package to update, but my Laptop had lost the network already.

Happens if you do "download on demand" strategy, like everyone with small disks.

In my case, 'zypper dup' downloads all packages first, yet NetworkManager-wifi was not downloaded and connection was lost after all downloaded packages were installed. So somehow the mechanism to install the recommended package failed for me, despite the default '/etc/zypp/zypp.conf' file.

'zypper dup' will not download newly added recommends. Even if

Of course it will. But recommend for -wifi was added several TW snapshots after package split.

I'm afraid it doesn't (at least not all of them). I just checked that after running 'zypper dup', a subsequent 'zypper install-new-recommends' indeed installs additional packages. This wouldn't be the case if new recommends are always installed by 'zypper dup' automatically. So that is probably what bit me here.

Zypper installs recommends for packages that are part of this transaction. Zypper will not install recommends for any package that is already installed but is not updated. I cannot reproduce it. After removing all NetworkManager* packages and installing only NetworkManager: tw:~ # rpm -q NetworkManager NetworkManager-1.36.4-2.2.x86_64 tw:~ # zypper dup Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... The following package is going to be upgraded: NetworkManager The following 3 NEW packages are going to be installed: NetworkManager-branding-openSUSE NetworkManager-tui NetworkManager-wifi 1 package to upgrade, 3 new. So NetworkManager-wifi is selected on update.

On Tue, 24 May 2022, Johannes Meixner wrote:

Hello,

On 2022-05-24 13:35, Simon Lees wrote:

...

On 5/24/22 20:41, Johannes Meixner wrote:

...

In contrast if a WiFi pattern was used "in between" the automatism may only request to install this pattern but the user could simply "taboo" this one pattern instead of "tabooing" a list of various individual packages which may change over time.

It doesn't work like this as patterns only Require or Recommend other software they don't Provide anything, so all you achieve by "tabooing" a pattern is that pattern won't be installed, if I had a wifi pattern "tabooed" it would not prevent NetworkManager-Wifi from being installed.

Sigh :-(

The more I learn about package dependencies the more I come to the conclusion that it could be impossible to use them to let the user choose what software is wanted or unwanted.

Perhaps only hard dependencies do actually work but weak dependencies are in the end a dead end?

Perhaps weak dependencies do not actually solve something but only mitigate/hide certain issues for average users while causing other problems for other users?

I think package dependences are not the correct tool to do decisions like this. In fact the only working option would be to Require every possible functionality that was enabled at build time which of course prevents you from selectively uninstalling parts that are not required by your specific system configuration. But unless you implement system configuration solely within the RPM framework and never edit, say, your pam configuration, but only ever configure by installing one of the N to-be provided pam-XYZ-config packages there's going to be situations where config and package dependences do not play together. So for the network manager example you'd have networkmanager require networkmanager-config, provide networkmanager-config-wifi and networkmanager-config-wired packages which in turn require networkmanager-wifi. And disallow manual editing of the configuration. A much better solution would be to ship configuration metadata for Yast (or any other system management tool) in the base networkmanager package so that tool can do the "feature" sub-package delection for you. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On 5/24/22 23:00, Syds Bearda wrote:

Would it be an option to add required to NetworkManager for NetworkManager-wifi for a few weeks and remove the hard dependency after a few weeks, to give people time to upgrade and then provide the recommended as the maintainers think is the best solution for the future?

Then at least the issue of breaking an installed system wouldn't happen..

/Syds

That is what i'm looking at for some similar style changes in the dbus package but more on that a bit later. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Tue, 2022-05-24 at 21:05 +0930, Simon Lees wrote:

...

In this particular example think about a computer with a WiFi adapter but for some reason the user does not want to use WiFi or must not use WiFi (e.g. it may be forbidden to use WiFi on that computer because of whatever restrictions in the environment where that computer is used) - then it could become rather complicated for the user to somehow disable the automatism by some rather low-level hacking.

I don't this as a big problem. With my original idea, the user can install "system-requires-wifi", or "pattern-hardware-wifi" if you prefer. This package/pattern might be autoselected by Yast if Wifi hardware was detected. The user would undo this selection, and be done with it. (Yast would need some way to remember that the auto-selected pattern had be deselected by the user, to avoid re-selecting it again and again).

We can and do achieve the same results without patterns, for example firefox and chromium both have the following in there spec files "Provides: web_browser" this way patterns and other software can recommend or require "web_browser" and if chromium is already installed it won't also install firefox.

But which entity would require "wifi"? That was the point. The user needs some way to specify that she wants Wifi support, in a way that package management tools understand. Whether that's implemented with a pseudo-package, a pattern, or some other means doesn't really matter. Also, I don't think NetworkManager-wifi would provide "wifi". No single package would provide this feature. "wifi" would rather mean something like "if some package is installed that has a subpackage for wifi support, install the wifi subpackage, too". Therefore I think what we want to achieve here can't be achieved with abstract provides and requires. We need conditionals and complex dependencies.

...

In contrast if a WiFi pattern was used "in between" the automatism may only request to install this pattern but the user could simply "taboo" this one pattern instead of "tabooing" a list of various individual packages which may change over time.

It doesn't work like this as patterns only Require or Recommend other software they don't Provide anything, so all you achieve by "tabooing" a pattern is that pattern won't be installed, if I had a wifi pattern "tabooed" it would not prevent NetworkManager-Wifi from being installed. I do not know this part of rpm well enough to know if "NetworkMangager-Wifi" had a "Provides: Wifi" if you could then taboo or add a lock that prevents all providers of Wifi from being installed, but if that doesn't work currently it would be much more likely to be implementable then tabooing a pattern tabooing everything inside the pattern.

AFAICS you don't need to taboo anything. You'd just need to make sure "pattern-hardware-wifi" is not installed, _and_ that there's no mechanism to re-install it automatically once the user deselected it. Currently, when we install on a multipath system, Yast opens a pop-up saying "The system contains multipath hardware. Do you want to install multipath?". This happens only during initial installation. The same could be done for Wifi. Martin

On Wed, 2022-05-25 at 20:21 +0930, Simon Lees wrote:

On 5/25/22 20:09, Martin Wilck wrote:

...

...

We can and do achieve the same results without patterns, for example firefox and chromium both have the following in there spec files "Provides: web_browser" this way patterns and other software can recommend or require "web_browser" and if chromium is already installed it won't also install firefox.

But which entity would require "wifi"? That was the point. The user needs some way to specify that she wants Wifi support, in a way that package management tools understand. Whether that's implemented with a pseudo-package, a pattern, or some other means doesn't really matter.

One option would be the Desktop patterns, another could be the installer detecting a wifi adapter and auto selecting it or both.

Both. The user needs to have the possibility to opt out.

...

Also, I don't think NetworkManager-wifi would provide "wifi". No single package would provide this feature. "wifi" would rather mean something like "if some package is installed that has a subpackage for wifi support, install the wifi subpackage, too".

If we are moving away from a world with Wicked then NetworkManager- wifi might be the only package that provides wifi, although I believe we still have connman in the repos which could also provide wifi and as long as one of those two packages are installed the user should wind up with working wifi.

You certainly understand that "wifi" was just an example. There are a lot of use cases for package dependencies that go beyound simple one- dimensional chains of "Requires" or "Recommends", even if wicked may be history some day.

...

Therefore I think what we want to achieve here can't be achieved with abstract provides and requires. We need conditionals and complex dependencies.

Possibly it depends how far we want to go and how much we really care about the migration for people with no-recommends, which ends up being I don't want almost all recommends.

We should either care about it, or make recommends work better, or move to a better dependency model.

Yep the question is whether its more sensible to do that logic by installing the NetworkManager-Wifi package, a meta package or a pattern, the advantage of the later two is we wouldn't need to update a hard coded value in the installer whenever we change the package.

Definitely not a hard-coded package in this case. Thanks, Martin

On Tue, 2022-05-24 at 09:22 +0200, Johannes Meixner wrote:

Second: All openSUSE package maintainers should specify RPM dependencies in the same way to get a consistent user experience.

Great goal. Can you explain how you intend to reach it. I believe it's hopeless for "Recommends:". "Recommends" means "the maintainer thinks that most users will find it useful to have package B installed together with package A". But not *all* users, otherwise the maintainer would have used "Requires". So how many is "most"? 70% ? 80%? 90%? And how do you even measure that? It comes down to an estimate, always. Very hard to do consistently if different human beings with different intuition are involved.

...

...

I believe that we have better instruments than "Recommends" these days, in particular booleans. In the example at hand, we could create a pseudo-package by the name of, say, "system-requires-wifi". Yast would install this package automatically during system setup if Wifi hardware was deteced. Then Networkmanager could have a dependency like this:

Requires: (NetworkManager-wifi = %{version} if system-requires- wifi)

RFC 1925 item 6a: "It is always possible to add another level of indirection."

RFC 1925 item 6: "It is easier to move a problem around   (for example, by moving the problem to a different    part of the overall [...] architecture)   than it is to solve it."

RFC 1925 item 5: "It is always possible to aglutenate [sic] multiple separate   problems into a single complex interdependent solution.   In most cases this is a bad idea."

What exactly do these generic words of wisdom help to solve the issue?

I think what software is usually needed by the user should be better specified via patterns.

Patterns also add another level of indirection but the patterns indirection is at least only one single generic and commonly known way to do that in contrast to various kind of individual levels of indirections at each specific RPM package.

Fair enough, if it comes down the same behavior.  What's important is that weak dependencies don't cut it. It's the conditional that matters. The combination of two requirements ("Networkmanager" and "wifi") maps to a *hard* requirement for "Networkmanager-wifi", whereas without "wifi", there would be *no dependency at all*. That's far better than the hand-waving "Recommends". If we can do this with patterns, fine with me. Martin

On Sat, May 21, 2022 at 1:29 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

On 21.05.2022 02:56, Neal Gompa wrote:

...

On Fri, May 20, 2022 at 6:40 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:

...

Am 19.05.22 um 13:38 schrieb Dominique Leuenberger / DimStar:

...

BEWARE: NetworkManager has been split into smaller chunks to better server various use cases, making it possible to be installed with smaller foot prints.

Users that decide to 'disable recommends' need to be extra careful here: the NetworkManager-wifi plugin is only recommended (NM on wired does not need the plugin).

Always keep in mind: disabling recommends means you claim you know better than others. so you have to live with the fact that non- mandatory features (which you would claim mandatory for your machine) are not automatically installed.

There is a section in our Wiki page about Package dependencies [1]:

...

The dependency resolution (installing *both* new packages) is done by YaST with the split-alias mentioned in Provides: of pac-devel.

[...]

During an update, the aformentioned split-alias tag is important. YaST only updates already installed packages, in this case only the main package. Without the split-alias, this would remove files needed for development which were part of the old main package but are not in the new main package.

Is that still recommended? There is a warning:

...

Split-alias tags are used by YaST only, RPM never sees them.

How about zypper though?

Aaron

[1] <https://en.opensuse.org/openSUSE:Package_dependencies#Splitting_a_package_into_two>

That documentation is more or less obsolete.

You forgot to explain how to make YaST/zypper/rpm to install NetworkManager-wifi on update from previous release before -wifi split.

The part that Aaron mentioned is most certainly not obsolete and actually works.

tw:~ # rpm -qil foo

Name : foo

Version : 1

Release : 1

Architecture: noarch

Install Date: Sat May 21 08:09:33 2022

Group : Unspecified

Size : 0

License : GPL

Signature : (none)

Source RPM : foo-1-1.src.rpm

Build Date : Sat May 21 08:03:53 2022

Build Host : bor-Latitude-E5450

Summary : testing subpackage split

Description :

Testing subpackage split

Distribution: (none)

/tmp/bar

/tmp/foo

tw:~ # zypper in -r local foo

Loading repository data...

Reading installed packages...

Resolving package dependencies...

The following package is going to be upgraded:

foo

The following NEW package is going to be installed:

foo-bar

1 package to upgrade, 1 new.

Overall download size: 11.7 KiB. Already cached: 0 B. No additional space will

be used or freed after the operation.

Continue? [y/n/v/...? shows all options] (y):

Retrieving package foo-1-2.noarch (1/2), 5.8 KiB ( 0 B unpacked)

Retrieving package foo-bar-1-2.noarch (2/2), 5.8 KiB ( 0 B unpacked)

Checking for file conflicts: .............................................[done]

(1/2) Installing: foo-1-2.noarch .........................................[done]

(2/2) Installing: foo-bar-1-2.noarch .....................................[done]

tw:~ # rpm -ql foo

/tmp/foo

tw:~ # rpm -ql --provides foo-bar

foo-bar = 1-2

foo:/tmp/bar

/tmp/bar

tw:~ #

...

If you're splitting packages, you should have Obsoletes: on each package being split out so that libsolv considers them upgrade candidates.

No, it does not work.

tw:~ # zypper info --obsoletes foo foo-bar

Loading repository data...

Reading installed packages...

Information for package foo:

----------------------------

Repository : local

Name : foo

Version : 1-2

Arch : noarch

Vendor :

Installed Size : 0 B

Installed : Yes

Status : out-of-date (version 1-1 installed)

Source package : foo-1-2.src

Summary : testing subpackage split

Description :

Testing subpackage split

Obsoletes : foo < 1-2

Information for package foo-bar:

--------------------------------

Repository : local

Name : foo-bar

Version : 1-2

Arch : noarch

Vendor :

Installed Size : 0 B

Installed : No

Status : not installed

Source package : foo-1-2.src

Summary : Package split from foo

Description :

Package split from foo

Obsoletes : foo < 1-2

tw:~ # zypper in -r local foo

Loading repository data...

Reading installed packages...

Resolving package dependencies...

The following package is going to be upgraded:

foo

1 package to upgrade.

Overall download size: 5.9 KiB. Already cached: 0 B. No additional space will be

used or freed after the operation.

Continue? [y/n/v/...? shows all options] (y):

...

You can also use Recommends from the old package to have the two others pulled in by default.

Have you tried to actually read this thread?

...

But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead.

It is not the question here. The question is how to make sure NetworkManager-wifi is installed after update from package version before split. You cannot assume everyone having NetworkManager also has desktop pattern.

So split-alias mentioned by Aaron actually work. My only complain is that it does not work with plain rpm, but then it is not clear how it can be made to work in the first place.

You've basically described a libsolv bug. RPM describes Obsoletes as working specifically in that manner: https://rpm-software-management.github.io/rpm/manual/dependencies.html#obsol... Per RPM, every package that has a matching Obsoletes: condition should be added to the transaction as an update to replace the old one. So if you have foo split into foo and bar, foo and bar should obsolete old foo, so RPM upgrades that package to have both of them. -- 真実はいつも一つ！/ Always, there's only one truth!

On Sat, May 21, 2022 at 8:49 AM Andrei Borzenkov <arvidjaar@gmail.com> wrote:

On 21.05.2022 15:27, Neal Gompa wrote: ...

...

...

...

If you're splitting packages, you should have Obsoletes: on each package being split out so that libsolv considers them upgrade candidates.

No, it does not work.

tw:~ # zypper info --obsoletes foo foo-bar

Loading repository data...

Reading installed packages...

Information for package foo:

----------------------------

Repository : local

Name : foo

Version : 1-2

Arch : noarch

Vendor :

Installed Size : 0 B

Installed : Yes

Status : out-of-date (version 1-1 installed)

Source package : foo-1-2.src

Summary : testing subpackage split

Description :

Testing subpackage split

Obsoletes : foo < 1-2

Information for package foo-bar:

--------------------------------

Repository : local

Name : foo-bar

Version : 1-2

Arch : noarch

Vendor :

Installed Size : 0 B

Installed : No

Status : not installed

Source package : foo-1-2.src

Summary : Package split from foo

Description :

Package split from foo

Obsoletes : foo < 1-2

tw:~ # zypper in -r local foo

Loading repository data...

Reading installed packages...

Resolving package dependencies...

The following package is going to be upgraded:

foo

1 package to upgrade.

Overall download size: 5.9 KiB. Already cached: 0 B. No additional space will be

used or freed after the operation.

Continue? [y/n/v/...? shows all options] (y):

...

You can also use Recommends from the old package to have the two others pulled in by default.

Have you tried to actually read this thread?

...

But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead.

It is not the question here. The question is how to make sure NetworkManager-wifi is installed after update from package version before split. You cannot assume everyone having NetworkManager also has desktop pattern.

So split-alias mentioned by Aaron actually work. My only complain is that it does not work with plain rpm, but then it is not clear how it can be made to work in the first place.

You've basically described a libsolv bug. RPM describes Obsoletes as working specifically in that manner: https://rpm-software-management.github.io/rpm/manual/dependencies.html#obsol...

Per RPM, every package that has a matching Obsoletes: condition should be added to the transaction as an update to replace the old one. So if

Where RPM is supposed to get this information in the first place? RPM does not work with repositories - all that RPM has is the list of packages in the current transaction. At most RPM may abort transaction if something is missing, but in this case nothing is missing at all - "foo" exists both before and after update.

...

you have foo split into foo and bar, foo and bar should obsolete old foo, so RPM upgrades that package to have both of them.

RPM cannot do it. You start with a system where foo is installed. If you do "rpm -U foo" there is nothing that tells RPM that bar is also "missing". If you already selected "bar" for installation together with "foo" then what you say is irrelevant because decision happened outside of RPM.

So in both cases it is up to higher level package management like libsolv to chose the right packages, and comparing

Provides: NetworkManager:.../libnm-device-plugin-wifi.so

and

Obsoletes: NetworkManager < V-R

in the NetworkManager-wifi, the former is certainly more logical and avoids issues with different V-R in different projects.

The former is a YaST/Zypp specific hack, the latter is *actually* how RPM wants you to do it. Moreover, if you download all the built NM packages and do "rpm -Uvh" on them, RPM would do the right thing. That's the point of using the actual RPM-defined behavior for this. This behavior is compatible with Zypp, YaST, DNF, and any other dependency resolver, whereas your Provides hack only works in YaST/Zypp. -- 真実はいつも一つ！/ Always, there's only one truth!

On 21.05.2022 15:53, Neal Gompa wrote: ...

...

of RPM.

So in both cases it is up to higher level package management like libsolv to chose the right packages, and comparing

Provides: NetworkManager:.../libnm-device-plugin-wifi.so

and

Obsoletes: NetworkManager < V-R

in the NetworkManager-wifi, the former is certainly more logical and avoids issues with different V-R in different projects.

The former is a YaST/Zypp specific hack, the latter is *actually* how RPM wants you to do it. Moreover, if you download all the built NM packages and do "rpm -Uvh" on them, RPM would do the right thing.

It will simply unconditionally install everything you throw at it. It is irrelevant whether there are some Obsoletes or not. The end result looks like what you wanted, but not because RPM does any magic, but because something decided to call RPM with the correct parameters. It is far from "RPM doing the right thing".

That's the point of using the actual RPM-defined behavior for this.

We are going in circle - *something* must have already decided to download *both* NetworkManager-wifi *and* NetworkManager. So whatever we are using this will *always* be "YaST/Zypp" hack.

This behavior is compatible with Zypp, YaST, DNF, and any other dependency resolver, whereas your Provides hack only works in YaST/Zypp.

RPM documentation does not cover the case of splitting off subpackage at all. What it tries to say - if package foo was replaced by package bar that Obsoletes package foo, then solver should select package bar for installation (and remove package foo actually). In this case NetworkManager still exists. So you have one of a) NetworkManager-wifi Obsoletes NetworkManager then you are not able to install NetworkManager and NetworkManager-wifi together at all b) NetowrkManager-wifi Obsoletes NetworkManager < cutover but then after update we have NetworkManager of version cutover+1 and condition does not apply at all, so there is no reason to select NetworkManager-wifi. Obsoletes is simply the wrong tool for this split.

On Sat, May 21, 2022 at 8:54 AM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:

Am 21.05.22 um 14:27 schrieb Neal Gompa:

...

You've basically described a libsolv bug. RPM describes Obsoletes as working specifically in that manner: https://rpm-software-management.github.io/rpm/manual/dependencies.html#obsol...

Per RPM, every package that has a matching Obsoletes: condition should be added to the transaction as an update to replace the old one. So if you have foo split into foo and bar, foo and bar should obsolete old foo, so RPM upgrades that package to have both of them.

That's not fully clear to me though. The documentation says simply

...

As a result packages containing matching Obsoletes: are added as updates and replace the matching packages. Is that *all* packages containing matching Obsoletes, or just *any one* with a matching Obsoletes? My reading would be that some packages are added until everything is matched up.

Possibly one of them could obsolete another, because there had been two new versions in the meantime. Then we can't install all of them. So if we wanted to say "all" we would probably need to qualify further.

...

There does not have to be a one-to-one relationship between obsoleting and obsoleted packages. That's simply saying what's not the case. And yes, surely multiple packages can obsolete the same package, but that doesn't imply all of them will be installed.

Another problem is that if we have NetworkManager and NetworkManager-wifi obsolete older versions of NetworkManager, the solver might see no need for NetworkManager-wifi: after all, since the new NetworkManager updates the old NetworkManager, there is no old NetworkManager to be obsoleted anymore.

Hmm, right, we don't have the ability to predict the Release value, do we? That does make things slightly tricky... Sadly, we don't have an openSUSE-release-container package that we could use for conditional Requires. If we did, we could do something fancy like this: Requires: (NetworkManager-wifi unless (openSUSE-release-container or MicroOS-release)) -- 真実はいつも一つ！/ Always, there's only one truth!

On Sat 2022-05-21, Andrei Borzenkov wrote:

...

But I recommend adding NetworkManager-wifi to the pattern metapackages for the desktops instead. It is not the question here. The question is how to make sure NetworkManager-wifi is installed after update from package version before split. You cannot assume everyone having NetworkManager also has desktop pattern.

Agreed. Still Neal's proposal would have helped some users, and generally seems to make sense, so could this be *one* aspect of addressing this? In addition to...

So split-alias mentioned by Aaron actually work.

? Gerald

On Thu, 2022-05-19 at 13:38 +0200, Dominique Leuenberger / DimStar wrote:

On Thu, 2022-05-19 at 11:00 +0000, Dominique Leuenberger wrote:

...

Packages changed:   NetworkManager (1.36.4 -> 1.38.0)

=== Details ===

==== NetworkManager ==== Version update (1.36.4 -> 1.38.0) Subpackages: NetworkManager-lang NetworkManager-pppoe libnm0 typelib-1_0-NM-1_0

- Recommend NetworkNanager-wifi from the main package: after the   split, there is currently nothing pulling in NM-wifi. Preferably   this would happen based on wifi chips prsence, but that is not   yet done (boo#1199550). - Modify NetworkManager.spec: Split into a few small subpackages   (bsc#1198128).

This update turns out to have more fallout. I'm running an openvswitch setup here, which ended up with no network connectivitiy after this update. Note that installing with --recommends wouldn't have prevented this: apollon:~ # zypper se --requires NetworkManager-ovs Loading repository data... Reading installed packages... No matching items found. apollon:~ # zypper se --recommends NetworkManager-ovs Loading repository data... Reading installed packages... No matching items found. apollon:~ # zypper se --suggests NetworkManager-ovs Loading repository data... Reading installed packages... No matching items found. Apparently OVS users are expected to figure this out by themselves, and install NetworkManager-ovs manually. Perhaps the changelog could have at least mentioned openvswitch, or in general listed _which_ subpackages had been split out? Anyway, something like Requires: (NetworkManager-ovs if openvswitch) in the split NetworkManager package would have saved me trouble. IMO conditional requirements like this are the solution to issues like this. Martin

On Mon, 2022-05-30 at 14:18 +0300, Andrei Borzenkov wrote:

...

%package ovs Summary:        Open vSwitch device plugin for NetworkManager Group:          System Environment/Base Requires:       %{name} = %{version} Requires:       openvswitch Supplements:    (NetworkManager and openvswitch)

Ok, got it. Sorry for overlooking that.

...

Apparently OVS users are expected to figure this out by themselves, and install NetworkManager-ovs manually. Perhaps the changelog could have at least mentioned openvswitch, or in general listed _which_ subpackages had been split out?

Anyway, something like

Requires: (NetworkManager-ovs if openvswitch)

Where? In NetworkManager? 

Yes.

Why should NetworkManager Require NetworkManager-ovs? Maybe the user is not going to control ovs with NetworkManager at all ...

Yes, maybe. Such a user would waste 87kiB of disk space (compare to 1.3 MiB for openvswitch, 5.9MiB for NM plus 1.4MiB for libnm0, and 6.8 MiB for wpa_supplicant). I am all for this sort of hard,rpm - conditional requirements, in particular for small plugins like this one. I suppose the split-alias technique would have worked, too. IMO the entire weak dependency concept needs to be reevaluated. As argued previously [1], "recommends" isn't well defined and probably never will be. Martin [1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/...

On Mon, 2022-05-30 at 16:25 +0200, Dominique Leuenberger / DimStar wrote:

On Mon, 2022-05-30 at 16:06 +0200, Martin Wilck wrote:

...

IMO the entire weak dependency concept needs to be reevaluated. As argued previously [1], "recommends" isn't well defined and probably never will be.

From an RPM PoV it is very clear how recommends are supposed to be used:

https://rpm-software-management.github.io/rpm/manual/dependencies.html

""" In addition to the strong dependencies created by Requires, there are 4 dependencies that are completely ignored by rpm itself. Their purpose is to be used by dependency solvers to make choices about what packages to install. They come in two levels of strength:

    Weak: By default the dependency solver shall attempt to process the dependency as though it were strong. If this is results in an error then they should be ignored and not trigger an error or warning.

    Very weak: By default the dependency solver shall ignore them. But they may be used to show the matching packages as option to the user. """

Which also matches what zypper does - the default is set to recommends on - so 'weak' deps are treated as required unless they run into conflict situations (e.g a conflict with other packages or a package lock by a user)

The very weak deps (suggest/enhances) are not installed - zypper gives some info about the suggested packages (and the pkglist gen bot, the one that calculates the content of e.g the DVD, takes them into account to add more packages onto the DVD, and in case of 'two packages providing the symbol, we use suggest to 'make the one win over the other if no better decision can be made).

Understood. But still it depends on the package maintainer's gut feeling whether she'll put "recommends", "suggests", or nothing at all.

What we should probably look at are all those weird recommends that result with tex being pulled in. Nobody wants tex - except the ones that DO and thse users are happily installing it manually (and have no right to complain :P )

Yes, TeX is a major reason why I'm disabling recommends in the first place. Being old-fashioned, I still use LaTeX/Lyx for certain tasks, but I need only a handful of LaTex subpackages. But I believe there are other areas as well in which recommends lead to a bloated system. I admit I don't know in detail, because I always disable them. For stuff like TeX, but also languages with lots of modules like Python, it would be nice if the tool itself was able to locate missing packages using the package management system. The point I'm trying to make is that more often than not, "Recommends" could better be expressed by conditionals or complex dependencies. Like the "Supplements" that NetworkManager-ovs already contains. If there was an option to tell zypper to enable this sort of "Supplements" while ignoring unconditional "Recommends", I'd enable it. Martin

On Mon, 2022-05-30 at 16:27 +0200, Ben Greiner wrote:

Am 30.05.22 um 16:06 schrieb Martin Wilck:

...

On Mon, 2022-05-30 at 14:18 +0300, Andrei Borzenkov wrote:

...

...

Requires: (NetworkManager-ovs if openvswitch)

Why should NetworkManager Require NetworkManager-ovs? Maybe the user is not going to control ovs with NetworkManager at all ... Yes, maybe. Such a user would waste 87kiB of disk space (compare to 1.3 MiB for openvswitch, 5.9MiB for NM plus 1.4MiB for libnm0, and 6.8 MiB for wpa_supplicant).

Correct me if I am wrong, but I believe that this does mean something entirely different: If openvswitch is available, then install it along NetworkManager and get NetworkManager-ovs as well. Now what does "is available" mean? Your approach assumes that it means "is installed".

I thought it meant "requires NetworkManager-ovs if openvswitch is also installed". That's what I intended to express, at least. If that's wrong, sorry for the noise. Of course I wouldn't want openvswitch to be always installed alongside NM. Martin

On Mon, 2022-05-30 at 17:16 +0200, Jan Engelhardt wrote:

...

I thought it meant "requires NetworkManager-ovs if openvswitch is also installed". That's what I intended to express, at least.

And that's what I think it does.

But think of all the people that have NM installed for NM's sake (e.g. ease of wireless) and who have have OVS installed for OVS's sake, but which still don't want NM-OVS :-D

Yeah, must be a million of them out there, and everyone wastes 87kiB. Horrible! Still hoping for someone to come up with The Ultimate Solution (R) for this problem. Martin

Am 30.05.22 um 17:16 schrieb Jan Engelhardt:

On Monday 2022-05-30 16:56, Martin Wilck wrote:

...

...

...

...

...

Requires: (NetworkManager-ovs if openvswitch) Why should NetworkManager Require NetworkManager-ovs? I thought it meant "requires NetworkManager-ovs if openvswitch is also installed". That's what I intended to express, at least. And that's what I think it does.

Let's stop thinking and guessing. Here is an experiment: https://build.opensuse.org/package/show/home:bnavigator:testbool/testbool skylab:~ #zypper lr 9 Alias          : home_bnavigator_testbool Name           : test rpm boolean deps (openSUSE_Tumbleweed) URI            : https://download.opensuse.org/repositories/home:/bnavigator:/testbool/openSU... weed/ Enabled        : Yes GPG Check      : (r ) Yes Priority       : 99 (default priority) Autorefresh    : Off Keep Packages  : Off Type           : rpm-md GPG Key URI    : https://download.opensuse.org/repositories/home:/bnavigator:/testbool/openSU... weed/repodata/repomd.xml.key Path Prefix    : Parent Service : Keywords       : --- Repo Info Path : /etc/zypp/repos.d/home_bnavigator_testbool.repo MD Cache Path  : /var/cache/zypp/raw/home_bnavigator_testbool skylab:~ #zypper info --requires testbool Loading repository data... Reading installed packages... Information for package testbool: --------------------------------- Repository     : test rpm boolean deps (openSUSE_Tumbleweed) Name           : testbool Version        : 0.1-2.1 Arch           : noarch Vendor         : obs://build.opensuse.org/home:bnavigator Installed Size : 9 B Installed      : No Status         : not installed Source package : testbool-0.1-2.1.src Summary        : Test rpm bool Description    :    Test how rpm boolean dependencies are resolved Requires       : [2]    (testbool-A if testbool-C)    (testbool-B if testbool-D) skylab:~ #zypper in testbool-C Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: testbool-C 1new package to install. Overall download size: 7.1 KiB. Already cached: 0 B. After the operation, additional 2.0 B will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package testbool-C-0.1-2.1.noarch                     (1/1),   7.1 KiB (    2   B unpacked) Retrieving: testbool-C-0.1-2.1.noarch.rpm ......................................................[done] Checking for file conflicts: ...................................................................[done] (1/1) Installing: testbool-C-0.1-2.1.noarch ....................................................[done] skylab:~ #rpm -qi testbool-C Name        : testbool-C Version     : 0.1 Release     : 2.1 Architecture: noarch Install Date: Mon May 30 18:47:58 2022 Group       : Unspecified Size        : 2 License     : WTFPL Signature   : RSA/SHA256, Mon May 30 18:41:41 2022, Key ID 795aeda43db1b31d Source RPM  : testbool-0.1-2.1.src.rpm Build Date  : Mon May 30 18:41:38 2022 Build Host  : build75 Vendor      : obs://build.opensuse.org/home:bnavigator Summary     : C Description : Pkg C Distribution: home:bnavigator:testbool / openSUSE_Tumbleweed skylab:~ #rpm -qi testbool-D package testbool-D is not installed skylab:~ #zypper in testbool Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 NEW packages are going to be installed: testbool testbool-A 2new packages to install. Overall download size: 14.4 KiB. Already cached: 0 B. After the operation, additional 11.0 B will be used. Continue? [y/n/v/...? shows all options] (y): n skylab:~ #zypper in testbool-D Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: testbool-D 1new package to install. Overall download size: 7.1 KiB. Already cached: 0 B. After the operation, additional 2.0 B will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package testbool-D-0.1-2.1.noarch                     (1/1),   7.1 KiB (    2   B unpacked) Retrieving: testbool-D-0.1-2.1.noarch.rpm ......................................................[done] Checking for file conflicts: ...................................................................[done] (1/1) Installing: testbool-D-0.1-2.1.noarch ....................................................[done] skylab:~ #zypper in testbool Loading repository data... Reading installed packages... Resolving package dependencies... The following 3 NEW packages are going to be installed: testbool testbool-A testbool-B 3new packages to install. Overall download size: 21.5 KiB. Already cached: 0 B. After the operation, additional 13.0 B will be used. Continue? [y/n/v/...? shows all options] (y): n I stand corrected. testbool-B is not pulled in automatically. That holds only true for BuildRequires in obs builds. - Ben

Am 30.05.22 um 21:57 schrieb Martin Wilck:

On Mon, 2022-05-30 at 18:54 +0200, Ben Greiner wrote:

...

I stand corrected. testbool-B is not pulled in automatically. That holds only true for BuildRequires in obs builds. So in my concrete example, if NetworkManager was installed and the user installed openvswitch later on, NetworkManager-ovs wouldn't be pulled in?

Yes, it would! It works both ways: Install testbool (NetworkManager) first, or testbool-C (openvswitch) first, testool-A (NetworkManager-ovs) wil be pulled in either way during the transaction when the second package is being installed. skylab:~ #rpm -q testbool{,-A,-B,-C,-D} testbool-0.1-2.1.noarch package testbool-A is not installed package testbool-B is not installed package testbool-C is not installed package testbool-D is not installed skylab:~ #rpm -q --requires testbool (testbool-A if testbool-C) (testbool-B if testbool-D) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rpmlib(RichDependencies) <= 4.12.0-1 skylab:~ #zypper --no-color in testbool-C Loading repository data... Reading installed packages... Resolving package dependencies... The following 2 NEW packages are going to be installed:  testbool-A testbool-C 2 new packages to install. Overall download size: 14.2 KiB. Already cached: 0 B. After the operation, additional 4.0 B will be used. Continue? [y/n/v/...? shows all options] (y): n The same is true for the `Supplements: (Network;anager and openvswitch)` defined in NetworkManager-ovs, which is IMHO the right place to put such a declaration. It's just that it is a "weak" dependency and is ignored if users deviate from the default config and choose to shape their system manually by ignoring `Recommends` et al. So we are back at square one of the discussion. - Ben

Dne pondělí 30. května 2022 21:57:54 CEST, Martin Wilck napsal(a):

On Mon, 2022-05-30 at 18:54 +0200, Ben Greiner wrote:

...

I stand corrected. testbool-B is not pulled in automatically. That holds only true for BuildRequires in obs builds.

So in my concrete example, if NetworkManager was installed and the user installed openvswitch later on, NetworkManager-ovs wouldn't be pulled in? I didn't expect that. It's debatable whether or not it's desired behavior. The end result depends on the sequence of package installations - if NM is installed first and openvswitch later, NM-ovs is not installed, but if openvswitch is installed first and NM later, it is. I find this surprising.

I suppose NM-ovs might be pulled in later when the NM package was updated while openvswitch was installed?

I run "zypper inr" regularly, so i guess it would get pulled by it then? Regards, Gryffus