Bug 1118510 - Major spec changes apparently intended for 22 were reverted, but the changed build reached mirrors: people with 0.81.0-4 builds will be stuck with them forever
Summary: Major spec changes apparently intended for 22 were reverted, but the changed ...
Alias: None
Product: Fedora
Classification: Fedora
Component: ceph
Version: 21
Hardware: All
OS: All
Target Milestone: ---
Assignee: Boris Ranto
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-10 22:18 UTC by Adam Williamson
Modified: 2014-08-17 16:00 UTC (History)
6 users (show)

Fixed In Version: 1:ceph-0.80.5-6.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-17 16:00:57 UTC

Attachments (Terms of Use)

Description Adam Williamson 2014-07-10 22:18:27 UTC
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,

Comment 1 Andre Robatino 2014-07-11 03:45:48 UTC
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.

Comment 2 Adam Williamson 2014-07-11 03:54:55 UTC
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.

Comment 3 Kalev Lember 2014-08-13 19:30:14 UTC
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.

Comment 4 Boris Ranto 2014-08-17 16:00:57 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.