On Wed, Jul 9, 2014 at 8:19 PM, Yasha Karant <[log in to unmask]> wrote:
> 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).

This was me. I thought I'd sent it to the list: it's all cool.


> 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.

Yeah, you can kind of tell it's me from that part....


> 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.)


The other dirty trick would be to use something like 'mock' to build a
chroot cage, and put your tools inside the chroot cage. Then set aside
the chroot cage for that application, specifically.

Attempts to provide application 'containers' that start to include
core components like glibc...... start getting very bulky, very fast,
and lose the performance advantages of a consistent library cache in
use throughoutt an operating system's  working environment. It's
*feasible*, and there are reasons to do it to segregate applications.
But it gets really resource expensive, really fast, and Linux is *not*
designed around it.