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.