SCIENTIFIC-LINUX-USERS Archives

March 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Thu, 19 Mar 2015 01:07:12 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (25 lines)
On Wed, Mar 18, 2015 at 11:27 PM, Yasha Karant <[log in to unmask]> wrote:
> I have been told that SUSE Enterprise Linux (SLES) supports, without
> problems or issues, an upgrade in place to migrate from major release N to
> N+1 without reformatting those parts of the disk / file system that contain
> systems files (e.g., /usr ,  /boot , etc.).  My understanding is that this
> is not possible/safe with EL -- e.g., SL6 to SL7.  Does anyone know if this
> is true -- and works?  If so, why does EL not support the same method?
>
> Yasha Karant

They've done so fairly successfully up to RHEL 7. Packages that might,
for whatever reason, have a "lower" build number are managed by the
use of the "epoch" setting in the .spec file, to announce that it is
really version 1:0.0.1, which is more recent than 0:4.0.0, and by
cautious use of name changes for various packages that might be
installed with newer versions on older operating systems. The classic
example right now is "autoconf", which may have a stack of versions
and name changes.

Where it gets nasty, and I'd lay good money you'd run into trouble
with your complex setups, is resolving dependencies nad updates for
third party repositories. If the "upgrade" tools don't have knowledge
of those unpredictable and out of scope packages, well, upgrade can
become a serious crapshoot.

ATOM RSS1 RSS2