during a yum update, I saw.. Updating : nfs-utils [ 66/212] Error unpacking rpm package 1:nfs-utils-1.1.2-12.fc10.i386 and then later.. Stopping RPC idmapd: [ OK ] Starting RPC idmapd: [ OK ] Stopping NFS locking: [ OK ] Stopping NFS statd: [ OK ] Starting NFS statd: [ OK ] Cleanup : nfs-utils [171/212] and the result is.. $ rpm -q nfs-utils package nfs-utils is not installed if the install stage breaks for whatever reason, we really shouldn't be running the cleanup stage. I'm just really thankful this happened to a bunch of non-critical packages. if it was glibc, I'd be completely hosed.
The problem is harder to fix than what is implemented in rpm-4.4.2.3.4.5.6.7... In general, package side effects, like Obsoletes: and/or upgrade, are dependent on the success of the install. In your case, the nfs-install package, which has a single dependent action, removing the old nfs-utils package. The general form of relations with the side effects of Obsoletes: and upgrades is many <-> many. Consider what should happen if the nfs-utils package carried several Obsoletes: as well as the implicit upgrade. Should the Obsoletes: be performed if the install fails? I think not. The many-to-many side effects dependent on the success (or failure) of the initial install (in yr case nfs-utils) is correctly handled in the @rpm5.org code base for several years now. Have fun!
Fixed in rawhide now.