Bug 1884954
Summary: | fio-engine-rbd exposing a bogus Provides: librbd.so.1()(64bit) breaking install on any apps using librbd1 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||
Component: | fio | Assignee: | Eric Sandeen <esandeen> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | agedosier, berrange, clalancette, esandeen, itamar, jforbes, laine, libvirt-maint, pportant, rjones, robatino, veillard, virt-maint, ykorman | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | openqa | ||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-10-19 21:43:13 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 1829022 | ||||||
Attachments: |
|
Description
Adam Williamson
2020-10-03 23:13:28 UTC
Libvirt has a link time dep on librbd.so.1: # ldd /usr/lib64/libvirt/storage-backend/libvirt_storage_backend_rbd.so | grep rbd librbd.so.1 => not found the RPM has auto-provides that lists this: # rpm -q libvirt-daemon-driver-storage-rbd-6.8.0-1.fc34.x86_64 --requires | grep rbd librbd.so.1()(64bit) fio-engine-rbd claims to provide this library: # rpm -q --whatprovides 'librbd.so.1()(64bit)' fio-engine-rbd-3.23-3.fc34.x86_64 but it does *NOT* provide it # rpm -ql fio-engine-rbd | grep rbd /usr/lib64/fio/librbd.so this appears to be an internal plugin for fio that is claiming same ABI/soname as the real librbd.so library If i manually install librbd1 then we see the clash: # rpm -q --whatprovides 'librbd.so.1()(64bit)' fio-engine-rbd-3.23-3.fc34.x86_64 librbd1-15.2.5-1.fc34.x86_64 IIUC, dnf install will prefer fio-engine-rbd because its name sorts first alphabetically. So, AFAICT, fio needs fixing so that its doesn't add Provides for its private plugins. Oh dear, this was me I'm afraid. The background is adding modular engine support for fio: https://src.fedoraproject.org/rpms/fio/blob/master/f/fio.spec#_31 Unfortunately it seems these engine names (*.so files) cause conflicting RPM dependencies because they have the same SONAME as the "real" libraries. > So, AFAICT, fio needs fixing so that its doesn't add Provides for its private plugins. Perhaps filtering them out in the fio package is the answer here? (In reply to Richard W.M. Jones from comment #2) > Perhaps filtering them out in the fio package is the answer here? Seems like it. (in the subpackage, right) I didn't know that was possible, but I guess it is? https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ Filtering the Provides seems to work. Before: $ rpm -q --provides -p x86_64/fio-engine-nbd-3.23-3.fc34.x86_64.rpm fio-engine-nbd = 3.23-3.fc34 fio-engine-nbd(x86-64) = 3.23-3.fc34 libnbd.so.1()(64bit) After: $ rpm -q --provides -p x86_64/fio-engine-nbd-3.23-4.fc34.x86_64.rpm fio-engine-nbd = 3.23-4.fc34 fio-engine-nbd(x86-64) = 3.23-4.fc34 https://src.fedoraproject.org/rpms/fio/c/7c3f48012b9bd06178a4263c31067b0cdd397de1?branch=master Let's see if this build solves the problem: https://koji.fedoraproject.org/koji/taskinfo?taskID=52807957 Thanks for the quick work here, guys. Yes, provides filtering works fine and is what you're supposed to do in cases like this. Richard, you might also want to check if any subpackages of fio got automatic *requires* on the soname and filter those too, otherwise they're going to now pull in librbd1 when they don't need to. Looking at the new Requires and Provides (see links here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1620357 ) and it looks OK to me. Note it's expected that the engines will Require various libraries (instead of core fio), because that's the point of the split. Hi, I'm the original contributer of the modular engine split in fio. This is my bug, the SONAME of the engine shouldn't match the name of the dependant library. I have a patch to fix this upstream [0]. I will attach it to this report in case you'd like to pick it up in the package until it goes upstream. I'm glad to see that the modular split is now enabled in Fedora, this was my original intent, just didn't get to sending the pull request [1]. [0] 0001-fio-fix-dynamic-engines-soname-definition.patch [1] https://src.fedoraproject.org/fork/ykorman/rpms/fio/blob/dynamic-libengines/f/fio.spec Created attachment 1719111 [details]
Fix for engine plugin SONAME
Thanks, here is a Fedora build containing that patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=52816959 Note I have left the Provides exclusion in as a safety net since we do not need the automatic dep generation for the fio engines. We can consider removing the exclusion in future. Yeah, it's still correct to exclude the auto-provides because packages shouldn't "provide" library sonames unless they're actually in the system shared library path and intended to be used as systemwide shared libraries. I believe this is all fixed now, closing. Re-open if any issues remain. |