Red Hat Bugzilla – Bug 454903
cpio failure on package update means package gets removed.
Last modified: 2015-01-04 17:30:38 EST
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-18.104.22.168.22.214.171.124...
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.
Fixed in rawhide now.