It looks like some major changes to the ceph package were planned for Fedora 22, but inadvertently landed before the branch point. These were then reverted. However, the changed build already landed in Rawhide *before* the branch point, so people who are tracking Fedora 21 have those changes:
http://koji.fedoraproject.org/koji/buildinfo?buildID=542028 - ceph-0.81.0-4.fc21 , containing the major changes - landed on July 4th, and was released to Rawhide repos
http://koji.fedoraproject.org/koji/buildinfo?buildID=542223 - ceph-0.81.0-5.fc21 , which reverted the major changes - only landed on July 7th
the -4 package was in the public repos for probably three days, and likely most Rawhide users updated to it. Consequently, it's not enough to just 'revert' the changes. -4 obsoleted a bunch of packages with new ones, and -5 does not re-obsolete them back to the old ones.
So, I have:
[adamw@adam x86_64]$ rpm -qa | grep 0.81.0-4
When I do yum update:
[adamw@adam x86_64]$ sudo yum update
No packages marked for update
none of the 0.81.0-5 packages gets pulled in to replace the 0.81.0-4 packages, because there are no Obsoletes: in place. Anyone who got the 0.81.0-4 packages is going to be stuck with them forever unless they work around this manually or you put some appropriately-versioned Obsoletes: in place (make sure not to paint yourself into a corner where it's no longer possible to get back to the 'new' layout again when upgrading to F22, or whatever).
If you don't want to fix things so people who got 0.81.0-4 get gracefully recovered, there at least needs to be public notification of this issue. I'm not sure if that's considered sufficient, though, there may be a policy that you *have* to fix the upgrade path,
When "yum list extras" (which I run every day in Rawhide to catch packages which are no longer in the repo) showed me that librados2, librbd1, and libcephfs1 were no longer in the repo, I removed them, along with a number of deps, then was able to reinstall the deps, which pulled in ceph-libs-0.81.0-5.fc21. The only unusual thing about this incident for me was that I had to remove and reinstall deps. So I think people using Rawhide should be encouraged to check their local packages against the repo frequently, as standard procedure.
well, no, it's pretty unusual that you'd have to do that. when packages replace other packages they are supposed to handle it with Obsoletes: / Provides: . that's how -3 replaced -2 in the first place.
I went ahead and fixed this for F21 / rawhide:
Might make sense to pull the fix to F20 as well to help users who got the split-up packaging through F20 updates-testing; I'll leave that to the ceph maintainers and the ticket open to discuss this.
Eventually, the changes were made and splitted-up packages landed in current f21.
Fixed in 1:ceph-0.80.5-6.fc21 -> closing. Feel free to reopen if the build did not fix the issue for you.