+++ This bug was initially created as a clone of Bug #1116546 +++ Description of problem: ceph-libs package is obsoleted by libcephfs1, librados2 and librbd1 from updates-testing, but none of those provide it. This leads to impossibility to, for instance, do `yum update`: Error: Package: 2:qemu-common-1.6.2-6.fc20.x86_64 (@updates-testing) Requires: ceph-libs >= 0.61 Removing: ceph-libs-0.81.0-1.fc20.x86_64 (@updates-testing) ceph-libs = 0.81.0-1.fc20 Obsoleted By: librbd1-0.81.0-4.fc20.x86_64 (updates-testing) Not found Available: ceph-libs-0.67.3-2.fc20.i686 (fedora) ceph-libs = 0.67.3-2.fc20 Available: ceph-libs-0.80.1-2.fc20.i686 (updates) ceph-libs = 0.80.1-2.fc20 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Version-Release number of selected component (if applicable): libcephfs1-0.81.0 librados2-0.81.0 librbd1-0.81.0 How reproducible: Always Steps to Reproduce: 1. Ensure you've got something that requires ceph-libs (e. g. qemu-common) installed 2. yum --enablerepo=updates-testing update Actual results: Error: Package: 2:qemu-common-1.6.2-6.fc20.x86_64 (@updates-testing) Requires: ceph-libs >= 0.61 Removing: ceph-libs-0.81.0-1.fc20.x86_64 (@updates-testing) ceph-libs = 0.81.0-1.fc20 Obsoleted By: librbd1-0.81.0-4.fc20.x86_64 (updates-testing) Not found Available: ceph-libs-0.67.3-2.fc20.i686 (fedora) ceph-libs = 0.67.3-2.fc20 Available: ceph-libs-0.80.1-2.fc20.i686 (updates) ceph-libs = 0.80.1-2.fc20 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Expected results: Successful update --- Additional comment from Ali Akcaagac on 2014-07-06 06:19:22 EDT --- Package ceph-libs is obsoleted by libcephfs1, but obsoleting package does not provide for requirements --> Finished Dependency Resolution Error: Package: 2:qemu-common-1.6.2-6.fc20.i686 (updates) Requires: ceph-libs >= 0.61 Available: ceph-libs-0.67.3-2.fc20.i686 (fedora) ceph-libs = 0.67.3-2.fc20 Available: ceph-libs-0.80.1-2.fc20.i686 (updates) ceph-libs = 0.80.1-2.fc20 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ---------------------------------- Please fix if possible. Wanted to open such a report too. --- Additional comment from Kaleb KEITHLEY on 2014-07-07 07:58:49 EDT --- --- Additional comment from Kaleb KEITHLEY on 2014-07-07 07:59:43 EDT --- --- Additional comment from Daniel Berrange on 2014-07-07 09:59:12 EDT --- IMHO the wholesale replacement of the Fedora ceph.spec file with a new one from upstream is a really inappropriate change and should be entirely reverted. Changing the sub-package layout in a stable Fedora release is in violation of the Fedora stable branch philosophy & guidelines, even if the upgrade path hadn't been screwed up. Such a wholesale replacement also really should require re-review against the Fedora packaging guidelines even in rawhide. --- Additional comment from Fedora Update System on 2014-08-17 11:43:08 EDT --- ceph-0.80.5-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ceph-0.80.5-6.fc20 --- Additional comment from Fedora Update System on 2014-08-19 03:05:11 EDT --- Package ceph-0.80.5-6.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ceph-0.80.5-6.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9535/ceph-0.80.5-6.fc20 then log in and leave karma (feedback). --- Additional comment from Ali Akcaagac on 2014-08-22 07:14:56 EDT --- I am irritated by the fact, that librbd1-0.80.5-6.fc20.i686.rpm created a /usr/lib64/<somelink> directory on a NON x64 architecture installation. The POSTIN file says: ;---------------------------------------------------------- /sbin/ldconfig mkdir -p /usr/lib64/qemu/ ln -sf /usr/lib/librbd.so.1 /usr/lib64/qemu/librbd.so.1 ;---------------------------------------------------------- Which is clearly wrong if someone is using an i686 architecture. With other words: Please make sure that the directory and it's symlinks are not being created during installation. Personally I am annoyed with directories that don't belong on these architectures. --- Additional comment from Fedora Update System on 2014-08-22 21:54:27 EDT --- Package ceph-0.80.5-8.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ceph-0.80.5-8.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-9535/ceph-0.80.5-8.fc20 then log in and leave karma (feedback). --- Additional comment from Fedora Update System on 2014-09-02 02:44:57 EDT --- ceph-0.80.5-8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from Ali Akcaagac on 2014-09-02 08:25:26 EDT --- What's with Comment #7 ? Ceph 0.80.5-8 still creates /usr/lib64/ directory with symlinks inside on a non x64 platform. This directory should not exist. --- Additional comment from Boris Ranto on 2014-09-02 09:37:21 EDT --- Hi Ali, this is a bit more complicated. The qemu looks exactly at the /usr/lib64/ location for librbd.so.1 (see [1] for details). This change was also a part of fedora/ceph package spec file sync-up. I'll look into this a bit further but it might be the case that this is a desired behaviour (at least while qemu will look into the hard-coded location). btw: Feel free to clone/open a new bz for the issue. It sure sounds like something that should be fixed in ceph/qemu/both. -Boris [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109895 --- Additional comment from Daniel Berrange on 2014-09-02 09:43:26 EDT --- The bug 1109895 describes what the qemu-kvm-rhev RPM on *x86_64* architecture requires. This qemu-kvm-rhev package does not exist on i686 or arm architectures. If qemu-kvm-rhev did ever exist on i686, it certainly not be looking in /usr/lib64/qemu. So Ali is right - this ceph RPM should *not* be creating a symlink of /usr/lib/librbd.so.1 -> /usr/lib64/qemu/librbd.so.1 In addition the quoted bug is refering to EPEL, so this symlink should only be added when building for EPEL, not for Fedora branches where qemu-kvm-rhev does not exist at all. --- Additional comment from Boris Ranto on 2014-09-02 10:16:36 EDT --- I did not write the fix for that bz, I just backported it as a part of spec file sync-up. I did not state that this is not a buggy behaviour (that is why I suggested Ali to clone this bz which I might do myself later) -- in fact, I stated the opposite -- that I will look into the problem a bit further -- to identify what the underlying problem really is. And yes, the bug is against epel but we try to use the same spec file for all releases (f19-f22, el6, el7). btw: While the referenced bug mentions qemu-kvm-rhev, afaik it is not just that package that looks for the ceph library at the location. --- Additional comment from Daniel Berrange on 2014-09-02 10:21:25 EDT --- (In reply to Boris Ranto from comment #13) > I did not write the fix for that bz, I just backported it as a part of spec > file sync-up. I did not state that this is not a buggy behaviour (that is > why I suggested Ali to clone this bz which I might do myself later) -- in > fact, I stated the opposite -- that I will look into the problem a bit > further -- to identify what the underlying problem really is. > > And yes, the bug is against epel but we try to use the same spec file for > all releases (f19-f22, el6, el7). Sure, just wrap the creation of the symlink in a conditional matching rhel >= 6 and arch == x86_64. > btw: While the referenced bug mentions qemu-kvm-rhev, afaik it is not just > that package that looks for the ceph library at the location. Yep, but this all stems from the virtualization stack on RHEL, whose multiple packages are all x86_64 only at this point in time. So we don't need to propagate this madness to other arches. --- Additional comment from Boris Ranto on 2014-09-02 10:46:15 EDT --- (In reply to Daniel Berrange from comment #14) ... > > Sure, just wrap the creation of the symlink in a conditional matching rhel > >= 6 and arch == x86_64. > That is what I wanted to do once I would make sure that qemu on i686 el6 (and x86_64 fedora 19+/el7) does not look at the location. Can you guarantee that it is not the case on those platforms? --- Additional comment from Daniel Berrange on 2014-09-02 10:50:58 EDT --- RHEL has never shipped qemu-kvm on anything except x86_64 arch. i686 is explicitly not supported.
I've looked into this and qemu-system-{x86_64,i386} in fedora links directly against librd.so.1 that is present in the appropriate /usr/lib|/usr/lib64 directory. Hence, there is no need to create the symlinks on fedora at all.
The packages that should fix this are currently being built in koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=7515135 [f20] https://koji.fedoraproject.org/koji/taskinfo?taskID=7515137 [f21]
ceph-0.80.5-9.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ceph-0.80.5-9.fc20
Package ceph-0.80.5-9.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ceph-0.80.5-9.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-10327/ceph-0.80.5-9.fc20 then log in and leave karma (feedback).
ceph-0.80.7-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ceph-0.80.7-1.fc20
ceph-0.80.7-1.fc20 has been pushed to the Fedora 20 stable repository.
This has been fixed, so how about closing this bugreport ?
I was giving this a few months long grace period when we cleaned up the mess that the symlinking caused and left this open for that period. As of few days back, we are no longer cleaning the lib64 mess in the builds so we can really close this one -> closing.