Elrepo Problem?
So much for elrepo being a painless way to get working Nvidia drivers…
Yum update (or just update glibc) says:
–> Processing Dependency: /usr/sbin/ldconfig for package:
nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64
–> Finished Dependency Resolution Error: Package: nvidia-x11-drv-304xx-304.123-1.el7.elrepo.x86_64 (@elrepo)
Requires: /usr/sbin/ldconfig
Removing: glibc-2.17-55.el7.x86_64 (@anaconda)
Not found
Updated By: glibc-2.17-55.el7_0.1.x86_64 (updates)
Not found You could try using –skip-broken to work around the problem
What do those ‘not found’s mean?
6 thoughts on - Elrepo Problem?
This isn’t elrepo’s fault.
The glibc update changes the location of the ldconfig binary. It’s still in root’s path, but anything that had a hardcoded path as a requirement will break.
The original glibc package provides both /usr/sbin/ldconfig and
/sbin/ldconfig, while the updated package only provides /sbin/ldconfig.
It means there’s no more /usr/sbin/ldconfig provided in the newer packages.
Ummm, great… I thought that was just the sort of breakage that
‘Enterprise’ OS versions were supposed to avoid. (I realize it’s not CentOS’s fault either).
The whole ‘s’ concept was a bad idea to begin with. Why did they have to make it worse?
Seems odd to say it twice. But what’s the right fix here?
Hi Les,
Actually I think Jim is being generous and I do take at least some responsibility for the breakage.
I’ve already committed a fix (below) but it won’t show up until the next nvidia legacy driver release:
https://github.com/elrepo/packages/commit/760a09a8147c4bc676dfa05c03d682255dbb52d6
For now, one workaround is to install the glibc update with –nodeps
(using rpm).
https://bugzilla.redhat.com/show_bug.cgi?id63607
Seems odd that with both the new and old glibc versions, rpm -q –whatprovides /usr/sbin/ldconfig says glibc-2.17-55.el7.x86_64
or glibc-2.17-55.el7_0.1.x86_64
yet yum doesn’t think so.
I guess symlinks really are evil and only useful for job security…
RPM has been able to handle symlinks for a long time:
$ rpm -ql kdelibs | grep libkunittest.so.4.13.3
/usr/lib64/libkunittest.so.4.13.3
$ rpm -qf /lib64/libkunittest.so.4.13.3
kdelibs-4.13.3-1.fc20.x86_64
I presume that yum is querying RPM for information about installed packages, causing the installed version of glibc to “automagically”
provide /usr/sbin/ldconfig. Let’s test:
# ln -s /usr/sbin /foo
# rpm -qf /foo/ldconfig
glibc-2.17-55.el7_0.1.x86_64
# yum provides /foo/ldconfig
…
glibc-2.17-55.el7_0.1.x86_64 : The GNU libc libraries
Repo : @updates
Matched from:
Filename : /foo/ldconfig
So yum has (and uses) more information about installed packages.