Bug 1136855

We want to push this change to f21 as well.


+++ This bug was initially created as a clone of Bug #1136811 +++

+++ 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.

--- Additional comment from Boris Ranto on 2014-09-03 07:21:11 EDT ---

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.