On 08/31/2014 06:35 PM, Nico Kadel-Garcia wrote:
On Sun, Aug 31, 2014 at 8:11 PM, David Sommerseth
<[email protected]> 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.
