# zypper inr
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 2 NEW packages are going to be installed:
godot-bash-completion poppler-data
# zypper search --recommends-pkg godot-bash-completion
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+-------+------------------------------------------------------+--------
| godot | Cross-Platform Game Engine with an Integrated Editor | package
poppler-data is listed because cups-filters is installed, but I could not find the reason godot-* is being recommended, since godot is not installed. Does anyone can explain? Or indicate another way to find the dependency? Thanks
The generated test case didn’t made it clear why, but returned that the package supplements another which is installed:
$ zypper if --supplements godot-bash-completion
Loading repository data...
Reading installed packages...
Information for package godot-bash-completion:
----------------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : godot-bash-completion
Version : 3.2-1.1
Arch : noarch
Vendor : openSUSE
Installed Size : 81.7 KiB
Installed : No
Status : not installed
Source package : godot-3.2-1.1.src
Summary : Godot command line completion for Bash
Description :
Bash command line completion support for godot, godot-headless,
godot-runner and godot-server
Supplements : [2]
bash-completion
godot
bash-completion is installed, but the zypper docs doesn’t mention that supplements are included with the inr command. Not sure how to verify that though.
In addition to dependencies that must be fulfilled, some packages “recommend” other packages. These recommended packages are only installed if actually available and installable. In case recommended packages were made available after the recommending package has been installed (by adding additional packages or hardware), use the following command:
sudo zypper install-new-recommends
This command is very useful after plugging in a Web cam or Wi-Fi device. It will install drivers for the device and related software, if available. Drivers and related software are only installable if certain hardware dependencies are fulfilled.
Also, because godot isn’t installed it wouldn’t be of any use. That’s the mistery.
Nope.
I didn’t install. Not that I need this package not to be installed, it’s a matter of learning how to interact with the system. I’ve added a lock to prevent installation anyways.
Depending on whatever you might mean by “supplements”
My guess is that this dependency probably needs to be fine-tuned and installed as a dependency in either the go developement language pattern or if there is such a thing as a dotnet go language (I’ve never heard of that), not as a BASH bash-completion dependency.
Perhaps a bug should be submitted for someone to evaluate?
info (if) [options] name...
Displays detailed information about the specified packages. + For each specified package, zypper finds the best available version in defined repositories and shows information for this package.
… –supplements
Show symbols the package supplements.
See also post #6.
On the other hand, if a package that is named foo or that Provides: foo is selected, and a package bar containing Supplements: foo” exists, then bar is also selected as long as doing so does not lead to unresolvable dependencies.
In other words, if you have packages A and B and you want to declare a weak relation between them A -> B, you can either specify it as package A containing Recommends: B or package B containing Supplements: A.
So the zypper inr command should install supplement packages. But why aren’t the other xyz-bash-completion installed?
I found this in the .spec for godot-bash-completion:
Supplements: (%{name} and bash-completion)
All other packages are defined in this fashion:
Supplements: packageand(%{name}:bash-completion)
The zypper info command presents them differently.
packageand(A:B). Usually used together with reverse dependencies, e.g. Supplements: packageand(A:B) proposes T only if both A and B are installed/to be installed.
Unlike the above mentioned dependencies, which are kind-of top-down, the following dependencies work the other way around. Read on.
Supplements: A reverse recommends. This resolvable will be installed if this capability is provided by an installed resolvable. The dependency resolver will install it. Uninstalling it is silently accepted.
Observed behavior is identical to described behavior: godot-bash-completion gets installed because it supplements bash-completion, which is already installed.
This assessment is incorrect because the package asks for bothgodot and bash-completion to supplement, using the and operator. The and operador is described in my previous message.
Package godot-bash-completion supplements both godot and bash-completion. However on my machine godot is not installed and bash-completion is installed. zypper install-new-recommends results in:
erlangen:~ # zypper inr
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 2 NEW packages are going to be installed:
godot-bash-completion opencv3
2 new packages to install.
Overall download size: 1.4 MiB. Already cached: 0 B. After the operation, additional 10.3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): n
erlangen:~ #
When none of the supplemented packages is installed:
erlangen:~ # zypper inr
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following 7 NEW packages are going to be installed:
ModemManager-bash-completion bash-completion godot-bash-completion mbimcli-bash-completion opencv3 pulseaudio-bash-completion subversion-bash-completion
7 new packages to install.
Overall download size: 2.0 MiB. Already cached: 0 B. After the operation, additional 11.2 MiB will be used.
Continue? [y/n/v/...? shows all options] (y):
Retrieving package bash-completion-2.10-2.1.noarch (1/7), 274.9 KiB (851.9 KiB unpacked)
...
(7/7) Installing: ModemManager-bash-completion-1.12.6-1.1.x86_64 ........................................................................................................................................................................................................[done]
erlangen:~ #
It was indeed an issue with the package, turns out the fix was already published the day before I posted here because I didn’t refresh the repo :shame:.