Seems possible solutions include:
1. whitelisting ntfsprogs (from ntfs-3g) somehow in mash to get multilib'd
2. consider adding a versioned Obsoletes: in ntfsprogs subpkg so the older nfsprogs.i686 pkgs get removed on upgrade.

The previous package was multilib due to having a runtime library (and gnome-vfs2 plugins.) The current package has neither of those things.

I'd definitely prefer the versioned obsoletes route.

See also https://bugzilla.redhat.com/show_bug.cgi?id=702671 , seems to affect epel-5 as well.

I'll go ahead and close this, as I think we're leaning toward trying to fix this in packaging via Obsoletes rather than involving any rel-eng intervention.

I'm not sure I follow. The e-v-r of the ntfsprogs subpackage is higher than the e-v-r of the old ntfsprogs standalone package. What exactly should I be Obsoleting? The problem is that the ntfsprogs.i686 package used to be in the repo and now it is not. I can't obsolete an architecture.

My understanding is that Obsoletes: will remove all architectures present, while a normal upgrade won't. Seth/James?

That's my understanding of Obsoletes too (I've done it several times in the past with other packages).

This is true, the only thing worthy of note is that the obsoletes will act like a delete on the old version ... so anything installed requiring ntfsprogs.i686, will get deleted if the user does "yum upgrade ntfsprogs".

This should be sorted out now with the latest batch of ntfs-3g updates