On 08/31/2014 06:35 PM, Nico Kadel-Garcia wrote:
> On Sun, Aug 31, 2014 at 8:11 PM, David Sommerseth
> <[log in to unmask]> wrote:
>> On 31/08/14 10:50, Yasha Karant wrote:
>>> On 08/30/2014 12:17 PM, David Sommerseth wrote:
>>>> It's a hack ... but you could probably install a newer Fedora or SL7
>>>> user-space into a chroot and run the application from that chroot. Look
>>>> at
>>>> --installroot in yum.  You just need to have the proper repo files handy
>>>> which yum (outside the chroot) would use - but only when you do the first
>>>> install. Afterwards, you can use 'yum update' inside the chroot as
>>>> before.
>>>>
>>>> Something along the lines of
>>>>
>>>>      yum install --enablerepo fedora --installroot /opt/fedora-root @core
>>>>
>>>> (given that you have the fedora repos handy)
>>>>
>>>> When that's done, you could just do:
>>>>
>>>>        chroot /opt/fedora
>>>>        yum localinstall $PKG
>>>>
>>>> At least in theory :)
>>>>
>>> I could use Fedora if I must in the manner suggested above, but I would
>>> prefer
>>> OpenSuSE to Fedora.  The other option is to wait for SL7 to leave beta and
>>> become production -- at which time we will routinely update all of our
>>> servers
>>> and workstations to the highest SL production version available (that is,
>>> SL
>>> 7x to replace the SL 6x we currently use).
>>
>> It can probably work as well.  I just demonstrated the yum method, as yum is
>> used in both Fedora and EL.  AFAIK, openSuSE doesn't use yum but zypper, and
>> I don't know how easy it will be to populate a chroot with a openSuSE root.
>>
>> As long as the glibc being installed in the chroot is recent enough to
>> understand the running kernel, this should work fairly well.
> One can also use 'mock' to build a quite complete chroot cage, just for testing.
Assuming that the SL 7 beta goes to production reasonably soon (?), SL 7 
is the most straightforward route, as we will
be migrating in any event.  For any major release of EL, we have learned 
the demanded methodology of a full overwrite/format/reinstall.
We have learned to keep all "local" and configured applications in 
partitions that do not require to be overwritten; thus, we have /usr/local
/opt , /home , and the like, not on a partition that needs to be 
rewritten.  We keep copies of /etc. /lib, /usr/lib and the like so
that configuration files that do not require rewriting can simply be 
reinstalled after the major release migration.  So long as these are
not configuration files required by the system and that change format, 
things work fine (e.g., we reinstall passwd and shadow from the
saved files).

In those cases when the configured application demands the older glibc, 
etc., we first attempt a clean rebuild of the application from source -- 
this generally has worked.