Bug 1116546

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.