When "yum upgrade" said: Installing: ntfsprogs x86_64 2:2011.4.12-3.fc14 updates 223 k replacing ntfsprogs.i686 2.0.0-15.fc14 replacing ntfsprogs.x86_64 2.0.0-15.fc14 Then errored with: file /sbin/mkfs.ntfs from install of ntfsprogs-2:2011.4.12-3.fc14.x86_64 conflicts with file from package ntfsprogs-2.0.0-15.fc14.i686 It seems incorrect to complain about (and fail because of) a conflict in a package that is being replaced.
Can you run: yum check ... just to make sure you don't have two copies installed or something weird.
I worked around the conflict by removing one of packages, so I don't have the setup any more, but I had greped rpm -qa and there were only two (i686 and x86_64).
Ahhah, bug 751574 made me see the light in this case: rpm only considers the obsolete from the newer ntfsprogs.x86_64 package to match the package of same arch (rpm internally doesn't look at the actual arch but the effect is the same). So while yum claims its replacing them both, rpm only replaces ntfsprogs.x86_64, leaving ntfsprogs.i686 in place, which causes the conflict. The current rpm behavior is what is wanted in most normal cases, but rpm has no way to express the situation here where a package used to be multilib but now its not, and the secondary arch package should just go away.
I assume this is just a special case of the multi-obsolete problem: if A and B both obsolete C, then any of A; B; A+B is a valid result (this is esp. a problem when one of A or B == C, so you _really_ need A+B to be the result). I assume noarch => arch; arch => noarch treated special? Is there a problem with just "fixing" rpm to ignore the arch. in this case?
(In reply to comment #3) > Ahhah, bug 751574 made me see the light in this case: rpm only considers the > obsolete from the newer ntfsprogs.x86_64 package to match the package of same > arch [...] I am digging and it seems even more prosaic than that: the ntfs-3g maintainer realized there can be this kind of problem and added this to the spec: # Needed to fix multilib issue Obsoletes: ntfsprogs < %{epoch}:%{version}-%{release} But we have a check in place that refuses any self-obsoleting (i.e. we ignore ntfsprogs's request to obsolete older ntfsprogs), not even getting to the color check. Will dig more into how to get rid of this.
I tested it, and disabling the self-deprecation check in RPM still doesn't obsolete the i686 ntfsprogs, because of the color rainbow mismatch (in practice we never allow obsoleting a package of color different from our rpmte color). And the fix I proposed for bug 751574 doesn't help here (http://lists.rpm.org/pipermail/rpm-maint/2011-December/003132.html). I think the solution is to allow general deprecation across colors, namely to: 1) allow depracating the package of a multilib architecture when multilib is no longer supported (as is the case in this bug) 2) allow deprecating a package of the same architecture yet different color (can happen, like grub in bug 751574). Note I am not speaking of allowing *upgrades* across colors here. The current behavior seems logical there.
Fixed on master: http://rpm.org/gitweb?p=rpm.git;a=commit;h=9cb5d5ccfbcfc454aace1a538199c76b0d931479
Related commit: http://rpm.org/gitweb?p=rpm.git;a=commit;h=b714dcea37af2e23026a52be76e7317592ecb52e This will warn e.g. if someone tries to build x86_64 with i686 binaries in it.
F14 is EOL by now, but fixed in rawhide as of rpm >= 4.10