View Issue Details

IDProjectCategoryView StatusLast Update
0000759channel: elrepo/el7primuspublic2017-07-21 08:03
Reporterprefect Assigned Totoracat  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Summary0000759: Provides for primus are incorrect
Descriptionprimus-20150328-1.el7.elrepo.x86_64

Provides: libGL.so.1()(64bit)

But it doesn't really, as it merely contains /usr/lib64/primus/libGL.so.1 which isn't in the library path.

primus can then get pulled in to satisfy a dependency that it really doesn't fulfill.
TagsNo tags attached.
Reported upstream

Activities

pperry

2017-07-21 02:58

administrator   ~0005332

The provides are generated automatically by rpm when the package is built, and as you note the package does provide /usr/lib64/primus/libGL.so.1 so technically the provides are correct.

However, I appreciate your point.

Please describe your actual issue, steps to reproduce etc. If you can explain how this is affecting you then we may be able to find a solution.

prefect

2017-07-21 03:09

reporter   ~0005333

You really can't claim to provide a library unless it's in the library search path, as you're then claiming to provide something no normal package is in a position to find and use.

https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Filtering_provides_and_requires_after_scanning

I guess I'm just suggesting something like:

%global __provides_exclude ^libGL.so.*$

For me this causes an installed machine to pull in primus to satisfy a libGL dependency, and means I get primus installed on lots of machines I don't want primus installed on. That then throws logs noise as a result of systemd trying to start bumblebeed on machines it can't possibly run on.

pperry

2017-07-21 04:02

administrator   ~0005334

Thanks for that. Having read the Fedora packaging guidelines you link I agree. I will arrange for the primus package to be rebuilt (hopefully today) to have the provides removed which should resolve the issue for you. I will confirm here once that is done.

Thinking out load...

To clarify, presumably you must be trying to install Xorg on a machine with elrepo enabled, and this is pulling in our primus package to satisfy the dependency for libGL.so.1 instead of the distro mesa-libGL package. If Xorg is installed before elrepo is installed/enabled, then mesa-libGL would already be present on the system so primus would not get pulled in to satisfy the dependency. This presumably must give you bigger problems than log noise (systemd failing to start bumblebeed) inasmuch as Xorg must be broken without a functioning libGL library but perhaps you are not using Xorg so wouldn't have noticed?

Primus is a new package to the repo, but nvidia-x11-drv which also provides libGL.so.1 has been present in the repo since it's inception, so I'm wondering why we have not seen this before with nvidia-x11-drv. What causes yum to select primus to satisfy the dependency for libGL.so.1 over mesa-libGL (and maybe mesa-libGL ahead of nvidia-x11-drv)?

prefect

2017-07-21 04:39

reporter   ~0005335

I accept I'm probably an odd case, but to add some flesh for interest:

Machine is installed pretty much bare, and then configuration management installs the rest, ending up with a fairly normal desktop machine. elrepo is enabled within %post of kickstart, so everything's setup and correct on first boot.

primus gets installed as a dep of qt-x11

At that point I only have two xorg packages installed:

xorg-x11-font-utils
xorg-x11-fonts-Type1

Later on mesa-libGL is actually pulled in as a dep of freeglut-devel (although other packages would pull it in too), and so the impact of this issue isn't as big as it could have been as we end up with the required packages anyway.

I *have* seen similar fun with nvidia/AMD but we actually deal with that, as I'd decided that was a problem of my own making. The nvidia-x11-drv *does* provide that library, and it does modify the library path, so I think claiming to provide that library is entirely valid.

In our case we currently do a sanity check at the end of post, where we remove kmod-nvidia\*, then use nvidia-detect to install the correct driver, which then covers all cases of machines without nvidia, current nvidia, or with old chipsets. I'll accept that's not ideal, and we should probably just get mesa-libGL installed earlier to avoid this jiggle.

No idea why it chooses one over the other. I lost enough time digging into how it manages groups/environment groups, so I'll park that bit of curiosity for now ;)

pperry

2017-07-21 08:03

administrator   ~0005336

Thanks for the background. It certainly helps us understand how the repo is being used and how we can best avoid such things happening.

I have rebuilt the primus package as primus-20150328-2.el7.elrepo.x86_64.rpm and pushed to the main elrepo repository.

Confirming the provides for libGL.so have been filtered out:

$ rpm -qp --provides primus-20150328-2.el7.elrepo.x86_64.rpm
primus = 20150328-2.el7.elrepo
primus(x86-64) = 20150328-2.el7.elrepo

I have also removed the old primus packages so they can no longer meet the dependency. Once our mirrors have updated, the issue should be resolved.

Many thanks for bringing this to our attention.

Issue History

Date Modified Username Field Change
2017-07-20 09:30 prefect New Issue
2017-07-20 09:30 prefect Status new => assigned
2017-07-20 09:30 prefect Assigned To => toracat
2017-07-21 02:58 pperry Note Added: 0005332
2017-07-21 03:09 prefect Note Added: 0005333
2017-07-21 04:02 pperry Note Added: 0005334
2017-07-21 04:39 prefect Note Added: 0005335
2017-07-21 08:03 pperry Note Added: 0005336
2017-07-21 08:03 pperry Status assigned => resolved
2017-07-21 08:03 pperry Resolution open => fixed