View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000759 | channel: elrepo/el7 | primus | public | 2017-07-20 09:30 | 2017-07-21 08:03 |
Reporter | prefect | Assigned To | toracat | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Summary | 0000759: Provides for primus are incorrect | ||||
Description | primus-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. | ||||
Tags | No tags attached. | ||||
Reported upstream | |||||
|
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. |
|
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. |
|
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)? |
|
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 ;) |
|
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. |
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 |