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
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_in...
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). 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". So in most cases --no-recommends probably isn't the best starting point for end users even experienced ones. Unless you are working on a very small limited use case like a container image to do a specific task, starting with the custom pattern, dummy installing the packages you want and looking at the list of pulled in recommends and blacklisting the ones you know you don't want. This is more work but much less likely to break in the long term then --no-recommends. -- 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