#4728 ntfsprogs update released without multilib, causing file conflicts
Closed: Fixed None Opened 9 years ago by kevin.

Moved over from infra trac:

The recent update of ntfsprogs (now from ntfs-3g) was only pushed as a x86_64 version to the F14 x86_64 updates repository but the release repo contains both i686 and x86_64 version. So whoever happened to have both the i686 and x86_64 versions installed now get a file conflict when trying to apply the updates.

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

Login to comment on this ticket.