nfs-utils-1.0.8.rc2-5.FC5 in dist-fc5-updates nfs-utils-1.0.8-2 in dist-fc6 The "rc" was erroneously added to the "Version" tag instead of the "Release" tag, causing the pre-releases of 1.0.8.rc2 to be newer by rpmvercmp than 1.0.8. You must either: 1) Bump the epoch. OR 2) Upstream goes to 1.0.9 or some higher number.
This seems to effect updates-testing too for Fedora Core 5.
(In reply to comment #1) > This seems to effect updates-testing too for Fedora Core 5. It's broken in rawhide as well. It was previously: nfs-utils-1.0.8.rc4-1 and is now nfs-utils-1.0.8-2 The problem is compounded by the fact that nfs-utils-libs was recently updated and since yum ignores the rebuilt nfs-utils it refuses to upgrade both. Yay.
Downloading the rpm and installing it with --nodeps and --oldpackage options to rpm work to get past the rc problem as Michal describes in the linked posting below. https://www.redhat.com/archives/fedora-test-list/2006-June/msg00404.html
This is making test rpms in FC5 very annoying at the moment. I'm sick of having to pass --exclude= in yum and don't think forcing a rpm install is the right solution since. Any chance of a fix soon?
Why not bump the epoch of rawhide rpm? Any reason?
jkeating wants to avoid the necissity of an Epoch bump by asking upstream to instead release 1.0.9. We're currently waiting for our NFS maintainer to come back from vacation. I personally feel that forcing upstream to release a higher number just for our sake is silly, and we should just rebuild it now in order to unbreak both FC5-updates-testing and rawhide. Epoch is ugly yes, but there is nothing technically wrong with it (anymore). We're delaying fixing this for poor emotional reasons.
Um, no. I don't want to force upstream to do anything. What I wanted to do was wait for our maintainer to get back, find out _what_ upstream has planned, and make a decision then. I'll find out today what the vacation schedule is and if it is too long, epoch will be introduced.
The theory is a new release 1.0.9 will be out around July 1 but I don't think there are any guarantees.... if that does not happen by then or there is not a definitive date by then I would suggest we introduce an epoch
Ah... Why was FC5-updates nfs-utils-1.0.8-1.FC5 released before this release number problem is solved?? Now, this problem annoys not only the people using FC6T1 or FC-devel, but also ALL people using FC5!! See: https://www.redhat.com/archives/fedora-list/2006-July/msg00011.html .
mtasaka, Yes this bug is annoying. However, it only affects those testing possible updates for FC5 and not people simply updating. See the following output. [rodd@localhost ~]$ sudo yum list | grep nfs-utils Password: nfs-utils.i386 1.0.8.rc2-5.FC5 installed nfs-utils-lib.i386 1.0.8-3.1 installed nfs-utils-debuginfo.i386 1.0.8.rc2-5.FC5 updates nfs-utils-lib.i386 1.0.8-4.FC5 updates-testing nfs-utils-lib-debuginfo.i386 1.0.8-4.FC5 updates-testing nfs-utils-lib-devel.i386 1.0.8-4.FC5 updates-testing [rodd@localhost ~]$ nfs-utils-lib is not in 'updates' but in 'updates-testing' and this particular repo is not enabled by default. You have to actively submit to being an update tester. As such, this isn't affecting everyone using FC5, just those that have edited /etc/yum.repos.d/fedora-updates-testing.repo and enabled it.
mtasaka, Mea Culpa. Muy Bad, Whoops. You're right, someone has added nfs-utils-lib-1.0.8-4.FC5 to updates. They've also added nfs-utils-1.0.8-1.FC5 to updates too. I wonder if someone has fiddled with the epoch on the later, or ....?
Nope, nfs-utils-1.0.8-1.FC5 doesn't install. I downloaded the file and tried rpm -Fvh nfs-utils-1.0.8-1.FC5 and it's not seen as an upgrade to nfs-utils-1.0.8.rc2-5.FC5 Hmmm, why was nfs-util-libs copied to updates? This strikes me as strange for two reasons: 1. It was know to be broken, and hadn't been fixed. (This one is obvious) 2. Given that it was broken, and that it had been placed into updates-testing, but so far is untested since you can't install it (at least not without forcing the issue), any possible fix for this install issue should logically be tested in updates-testing to allow the file to actually be tested before uploading to updates. (hope the wasn't too convoluted ;-]). I wonder what happened?
I don't know well about test-release cycle... however it is apparent that: A. Now update version nfs-utils-lib-1.0.8-4.FC5 and libgssapi-0.9-1.FC5 requires nfs-utils-1.0.8-1.FC5. B. But nfs-utils-1.0.8-1.FC5 is not treated as a update of nfs-utils-1.0.8.rc2-5.FC5 . I hope this problem will be fixed immediately......
Same problem, seen in regular non-test version of FC5. After upgrading to libgssapi-0.9-1.FC5, I removed nfs-utils and nfs-utils-lib, then did "yum install nfs-utils-1.0.8" which seems to have worked: Installed: nfs-utils.x86_64 0:1.0.8-1.FC5 Dependency Installed: nfs-utils-lib.x86_64 0:1.0.8-4.FC5 Nevertheless, this procedure should not be required in regular FC5. A fix is needed.
We must have a rule and a procedure that quickly remove broken packages from repository. This kind of dependency problem must be considered a security-problem because it avoid to apply other security updates.
I completely agree, which is why I called this "emotional reasons" for not doing it sooner with an Epoch bump.
Any solution/work-around to this problem? Any chance to rush 1.0.9/epoch version to update-testing ASAP?
The maintainer will fix this when offices open again July 5th.
nfs-utils-1.0.8-2.fc5 has been pushed for fc5, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Okay, the epoch of nfs-utils is incremented to 1 on nfs-utils-1.0.8-2.fc5 and this rpm solves the problem. libgssapi-0.9-1.FC5.i386.rpm nfs-utils-lib-1.0.8-4.FC5.i386.rpm nfs-utils-1.0.8-2.fc5.i386.rpm work well as for upgrade for me. This problem is now solved for FC5. Thanks.
I second the above. FC5/x86_64.
(In reply to comment #20) > This problem is now solved for FC5. Thanks. Sorry, ran into the problem on my FC5 running yum update just now. It aint fixed.
(In reply to comment #22) > (In reply to comment #20) > > This problem is now solved for FC5. Thanks. > > Sorry, ran into the problem on my FC5 running yum update just now. > > It aint fixed. > Lets see some output. Perhaps you're hitting a stale mirror.
This problem is fixed in the latest Rahide release
Unfortunately, FC5 update had Epoch 1, but 1.0.9 in FC6 had no Epoch. Adding Epoch to FC6 so there is a smooth upgrade path.