I was trying to set up an app that has certutil as one of its dependencies, however, I cannot seem to find any package for openSUSE that contains this tool.
On debian based systems there is libnss3-tools, but cannot find anything similar for openSUSE, although this tool appears in the wiki in articles that deal with certificates.
What am I missing?
It’s so unusual for me to NOT find a package on openSUSE, that now I start to freak out
+1 for using cnf, I too didn’t know about it until today.
My usual goto when zypper wp didn’t work was to use zypper se --file-list <search-term> but it produces unwanted output.
I ended up with this eventually: zypper se --file-list /^certutil$/
No idea how the regex for latching onto start and end of string works out here as the actual filename as per rpm -qpl is /usr/bin/certutil
To make this topic complete, I used the suggested command (cnf) and it returned the package that I needed to install in order to get certutil.
:~> cnf certutil
The program 'certutil' can be found in following packages:
* mozilla-nss-tools [ path: /usr/bin/certutil, repository: download.opensuse.org-oss ]
* mozilla-nss-tools [ path: /usr/bin/certutil, repository: openSUSE-20240412-0 ]
Try installing with:
sudo zypper install <selected_package>
Congratulations, because you never make typos when typing a command. Because when you do it says:
boven:~ # bloeb
If 'bloeb' is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf bloeb
boven:~ #
So most of us have seen that umpteeth times.
In Tumbleweed, cnf is installed, not scout-command-not-found
Install zypper in scout-command-not-found
by deleting the installed cnf packages.
close the Terminal and start a new one.
Try it
tumbleweed:/home/stephan # lsb-release -id
Distributor ID: openSUSE
Description: openSUSE Tumbleweed
tumbleweed:/home/stephan # bloeb
Wenn 'bloeb' kein Tippfehler ist, können Sie command-not-found benutzen, um das Paket zu finden, das den Befehl enthält, z. B.:
cnf bloeb
Thanks, looks like Tumbleweed-Slowroll does things differently:
pavin@suse-pc:~> sudo zypper in scout-command-not-found
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: 1: the installed cnf-bash-0.6.0~0-3.4.noarch obsoletes 'scout-command-not-found < 0.2.8' provided by the to be installed scout-command-not-found-0.2.7+20230124.b4e3468-2.2.noarch
Solution 1: Following actions will be done:
deinstallation of cnf-bash-0.6.0~0-3.4.noarch
deinstallation of cnf-0.6.0~0-3.4.x86_64
Solution 2: do not install scout-command-not-found-0.2.7+20230124.b4e3468-2.2.noarch
Choose from above solutions by number or cancel [1/2/c/d/?] (c):
Personally I don’t mind the way it is now, showing the installation help only when the match exists.
pavin@suse-pc:~> certutil --help
The program 'certutil' can be found in following packages:
* mozilla-nss-tools [ path: /usr/bin/certutil, repository: base-oss ]
* mozilla-nss-tools [ path: /usr/bin/certutil, repository: base-update ]
Try installing with:
sudo zypper install <selected_package>
pavin@suse-pc:~> bloeb --help
bloeb: command not found
Obsoletes alter the way updates work. This plays out a bit differently depending whether rpm is used directly on the command line or the update is performed by an updates/dependency solver.
RPM removes all packages matching obsoletes of packages being installed, as it sees the obsoleting package as their updates. There does not have to be a one-to-one relationship between obsoleting and obsoleted packages. Note that rpm -i does not do updates and therefore treats Obsoletes: as Conflicts: (since rpm-4.10). For most cases rpm -i should be avoided and rpm -U should be used unless this specific behavior is desired (e.g. for kernels).
Updaters have a slightly different view on Obsoletes: as they need to find out what packages to install as an update. As a result packages containing matching Obsoletes: are added as updates and replace the matching packages.
my face burns now 
, doesn’t work that way on may machine though 
