In my SL5, i386 computer, with the yum-priorities rpm installed, in
/etc/yum.repos.d the sl-contrib repository has "priority=10", the dag
repository has "priority=30", and the epel repository has no priority set.
According to
http://wiki.centos.org/PackageManagement/Yum/Priorities
"Packages from repositories with a lower priority will never be used to
upgrade packages that were installed from a repository with a higher
priority." and it also says "The default priority for repositories is 99.
The repositories with the lowest numerical priority number have the
highest priority." If I'm right about why you couldn't get the ntfs-3g
version you wanted, it might also work to leave sl-contrib enabled, but
add "priority=10" to the [epel] section of epel.repo. But since most
repositories, including sl-security, have "priority=10", I'm worried that
epel could then replace SL security updates, for example. So it may be
safer to instead remove the "priority=10" line in the sl-contrib repo, or
just temporarily disable sl-contrib, as I previously suggested.
Steven Yellin
On Fri, 16 Dec 2011, Steven J. Yellin wrote:
Although the version of ntfs-3g with libntfs-3g.so.81 is in epel,
according to the output of your 'yum --enablerepo=epel install ntfs-3g'
command, yum got ntfs-3g from the sl-contrib repository. Two relevant lines
of your output are:
Package Arch Version Repository Size
ntfs-3g i386 2:1.1104-3.sl5 sl-contrib 147 k
So here's an hypothesis about what's going on: maybe sl-contrib is enabled,
has a version of ntfs-3g that's older than the one you want, and yum doesn't
look in epel once it's satisfied with what it learned from sl-contrib. Try
disabling sl-contrib. And you might also do 'yum clean all'. Then I'll bet
an update will get Version 2:2011.4.12-5.el5.
Steven Yellin
