Red Hat Bugzilla – Bug 196359
FC5 -> FC6 nfs-utils version goes backwards
Last modified: 2013-01-09 22:57:05 EST
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.
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.
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 .
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
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
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
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.
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
B. But nfs-utils-1.0.8-1.FC5 is not treated as a update of
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
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.
work well as for upgrade for me.
This problem is now solved for FC5. Thanks.
I second the above.
(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.