This post is a follow-up to Re: [SCIENTIFIC-LINUX-USERS]
glibc-2.15-60.el6.x86_64.rpm [correction]. I had forgotten this trick,
but I received an off-list email that explained what to do. This sort of
information should be kept in a central SL (or EL or CentOS, etc.)
repository -- a practicum of how-to workarounds -- as it used to be for
BSD and SunOS a rather long time in the past. As the correspondent did
not use the SL list, I am assuming that she/he wishes not to be the
public author of the commentary below (slightly edited).
Quote.
Use rpm2cpio to unbundle the glibc into an alternative location in
"/opt". Put shell wrappers in $HOME/bin that set LD_LIBRARY_PATH,
MANPATH, etc. to the new location. Install the binary, as well, in ta
parallel location in /opt., also accessed by the wrapper. Try using
the shell wrappers to summon the binaries with those variables set to
point to the new library
*DO NOT* use RPM to install this, even if you succeed you're likely
to seriously break the system. It's like replacing the motor on a car
while it's running, replacing a diesel with a Wankel motor.
End quote.
Note that after I update a major library, I do not attempt to keep the system
running, but reboot, with the pre-updated libraries available in such a form
that I can use the shell from a rescue DVD (or USB if one must) to redo the
links. (E.g., if this is libmajor.so.M and it is replaced by libmajor.so.N, N
.ne. M, then before any such attempted installation, I do a cp -pr of
libmajor.so.M to orig-libmajor.so.M, and if the rescue method must be used, mv
libmajor.so.N to new-failed-libmajor.so.N and mv orig-libmajor.so.M to
libmajor.so.M. Note that is a time consuming set of steps that requires
physical access. Polymorphic virtualisation of file systems nominally could
avoid this methodology, but has other problems and risks.) I do thank the
private correspondent for the workaround. Hopefully, the shell wrappers will
work (a shell wrapper for each application file that requires the other
environment.)
