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
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.
*** Bug 1116787 has been marked as a duplicate of this bug. ***
*** Bug 1116614 has been marked as a duplicate of this bug. ***
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.
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
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).
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.
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).
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.
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.
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
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.
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.
(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.
(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?
RHEL has never shipped qemu-kvm on anything except x86_64 arch. i686 is explicitly not supported.