Nsight-compute replaces Fedora package provided dependencies when attempting to install wireshark

So I thought of installing Wireshark today. I searched the repositories to see if it exists.

(It did)

I went onto install it and then, I saw this.

Wireshark somehow needs nsight-compute-2019.4.0 - which is of course 257MiBs big.

Not just that, it hails from an entirely unrelated repository of CUDA drivers.

Of course, I took hint from the reponame column and looked it up.

and went ahead to disable it - before trying to install Wireshark again.

This adds qt5-qmultimedia and openal-soft as two dependencies as a replacement to the nsight-compute-2019.4.0.

I think there’s something wrong with resolving the package names when there are multiple repositories having multiple packages but with the same name. Of course, a sane way of solving this would be to pick the one having a greater version number but this also makes it a critical vulnerability as well. Imagine, if I went ahead and created a COPR for nano with version ahead than 5.3-4. :joy:

Is there a way to make sure this does not happen?


Looks like nsight-compute-2019.4.0 provides some of the wireshark dependencies and somehow wins over qt5-qmultimedia and openal-soft. I think this is why adding too much 3. party repos is frowned upon and at some point breaks your installation. Adding some arbitrary repo is definitely a security risk and you can prevent this with sticking with the well known and trusted repos, like RPMFusion.


So, wireshark doesn’t need it. This package, for some reason, is providing a capability that wireshark depends—which in Fedora are fulfilled successfully by the other dependencies. You can check capabilities that a package provides using dnf repoquery --provides <package name>. I’m sure you’ll find that the nsight-compute one provides stuff that the qt5-qtmultimedia etc. provide. Maybe it just bundles them—who knows what’s in the 260MiB rpm! XD

You can use the priority setting in the repository’s config file to ensure that packages from the Fedora and RPM Fusion repositories are always preferred to other repositories. man dnf.conf for more info on how to use it.

I’ll update the topic here to better describe the issue, since “wireshare now needs CUDA software as its dependencies” is not an accurate description :slight_smile:


Well that explains why COPR, even when one of the reliable places to build packages, still isn’t officially supported by the infrastructure. Resolution of packages with same name across multiple repositories is still a gray area as there’s no order of precedence that is maintained in the repository listing when fetching the packages. A package with a greater version will supercede even when it hails from a non-default repo.

1 Like

That would be a worthwhile experiment that would keep me entertained and also help with some deductions.

Wait. Is there a way of setting priority across repositories? Why don’t we have a quick doc about it yet? :flushed:

Yes, please go ahead and do so. The installation of Wireshark before repo disabling had a funny outcome hence I decided to give a funny title to the post noting the observation. :smile:


I’d say because it’s an advanced config and we don’t want users installing random third party repos just because they can tweak repository priority. It really isn’t something that everyone should be using. A majority of our user base should be sticking to Fedora + RPMFusion, and the advanced folks should be advanced enough to read the man pages :slight_smile:

PS: if you can get in touch with the provider of this cuda repository, you should inform them that they’re providing badly packaged rpms that overrun Fedora packages. If this is necessary, they should clearly document this so that their users are aware.

sudo dnf config-manager --save --setopt=cuda\*.priority=100
sudo dnf config-manager --dump \* | grep -e ^= -e ^priority

DNF Configuration Reference — dnf latest documentation

Perhaps the defaults should be reconsidered to not override the official repos unless the priority is specified explicitly in the repo file, i.e. change the official repos priority to something like 50 by default.

@mattdm, is it possible to propose this change for the next release?


Thanks @vgaetera. This should be out known to folks as well who use custom repositories to avoid such a mishap. :grinning_face_with_smiling_eyes:

1 Like

I actually have been doing that, trying to find ways to communicate the maintainer to see if the dependencies could be slimmed down and made specific.

Plus there has been this thing going on - take a look Port this to RHEL/CentOS if possible as a project · Issue #16 · gridhead/nvidia-auto-installer-for-fedora-linux · GitHub. RHEL is actually suggesting installation of binaries from the official website even when the RUN file is generic. I know it is not related to the topic but it still is a packaging hazard. :worried:

1 Like