[CentOS] Upgrading from CentOS 5.6 to 6.0

[夜神 岩男]

On 07/26/2011 01:32 PM, R P Herrold wrote:
> On Tue, 26 Jul 2011, Mike Burger wrote:
>
>> If IBM can make this happen for their OS, and Red Hat certainly supports
>> such a process in the Fedora line of releases (including the ability to
>> list additional repositories for remote installation as part of the
>> process), they could certainly make it a supportable option for the RHEL
>> line.
>
> The upstream supports nothing as to Fedora, and indeed,
> members of that project regularly (and seem to gleefully)
> break forward compatability
>
> But you are missing the point -- WHY spend the engineering
> effort on trying to support such Major 'upgradeany's?  A new
> deployment takes mere minutes for a commercial shop, and by
> NOT supporting such explicitly, the upstream avoids much
> support and engineering load.
>
> [I say this having done an 'upgradeany' and run into a later
> 'nss' in C5 than the C6 initial media provides, that required
> some head scratching, and a nasty workaround, to solve over
> the weekend]

RPH is definitely right about "gleefully breaking forward compatibility".

It is easier to control compatibility backward and forward when you're 
deploying a closed (or at least tightly controlled) system as opposed to 
one that boils with change the way the Fedora upstream does.

Example: systemd

Find a way to make a transition from 6x to 7.0 seamless by way of a 
simple "yum update" once SysV init goes away and all system services 
must grow configuration files and drop init scripts. That's just one 
subsystem, there are other huge changes as well (Gnome3...).

IBM and the tightly controlled (and decades long) OS/360 -> z/OS process 
or their linear passes through AIX Ver.n -> Ver.n+i do not compare to 
Red Hat's situation. Anyway, compatibility is often complex enough for 
IBM to address by quietly including emulators for their previous systems 
instead of shooting for base compatibility.

The key to Red Hat's success has been its hands-off approach to the 
Fedora Project. If Red Hat ever desires to implement something they must 
first present working implementations for acceptance by FESCo -- which 
implies promising, working implementations. This forces a lot of unique 
situations, but the primary effects are:
  * Advances occur at a rate difficult to compare to other projects
  * Entire subsystems can be marked "obsolete" if a working 
implementation demonstrates superior function (systemd ousting the 
venerated SysV init is an example of this "nothing sacred" attitude)
  * Technical debate about anything/everything crosses company, private 
and personal lines in ways difficult to interpret from a traditional 
development perspective
  * The chaos level is high (marked by the inability for any one person 
to be an expert on everything at a given time -- by the time one thing 
is thoroughly understood something else has changed)
  * Absolute forward and backward compatibility requires too much 
effort, so the concept of "compatibility" moves up two levels to the 
data layer[1]

IBM, on the other hand, has a long-term compatibility program they 
consider to be at the core of their business model (System/360 history 
is interesting here). They plan their changes around a few subsystems 
they consider to be sacred. If you want to change something sacred you 
have to plan it out through the high priest in charge of that subsystem 
-- and it is acceptable for major system changes to take several years.

The whole thought process is entirely different -- as are their target 
markets. Red Hat is a good value for large- to huge-sized businesses, 
and IBM is a better value (sometimes with a mix of Red Hat in some 
areas/departments) for titanic- to ZOMG-sized businesses.

I apologize for the long message. I didn't have time to write a short one.

-Iwao

[1] I've been thinking about this a bit and I've come to think that 
there are roughly three layers to compatibility -- so I'll define them 
here since I referenced my own definition:

1- Absolute forward and backward compatibility. Code builds and runs in 
exactly the same way on any system in the series.

This is the level IBM shoots for. System upgrades and downgrades are 
clean, reliable and easy to recommend and support.

In Linux terms this would mean you could load, say, RHEL 3 and "yum 
upgrade" to RHEL 6.1 -- whether that is through a yum-initiated upgrade 
chain or a one-step upgrade is of no concern to the user.

2- Configuration compatibility. Implementations change in radical ways, 
but the interpretation, format and semantics of configuration files is 
absolutely respected between versions and often between competing 
implementations of a single standard. OpenLDAP's move to cn=config while 
retaining the ability for slapd.conf to be read and converted to a 
cn=config loadable set of LDIFs is an example of this.

This is roughly what Microsoft used to aim for (somewhere on the road 
between XP and 8 they seem to have totally quit the idea, though).

In Linux terms this would mean you can copy things like /etc, /var and 
/home/~/.* and add the contents to whatever new is in the upgrade and 
not endure any major shocks.

3- User data compatibility. Config files might change, because entire 
subsystems might evaporate or be replaced. Converting between radically 
different concepts (Gnome 2 to 3 with gconf to dconf, for example) means 
that finding enough logical parallels to define a user/upgrade friendly 
automatic conversion tool is at least as difficult as developing the 
replacement system was in the first place -- and therefore an 
unrewarding level of effort. User data, on the other hand -- being the 
actual media, business files, whatever, are considered sacred, however, 
and the system must be able to support loading the old media onto the 
new system. Universal support for ODF, import support of database dumps 
between PostgreSQL versions or MySQL to MariaDB, universal image 
formats, JwCAD .jww export to .dxf and import to LibreCAD, mbox, etc. 
are examples of this level.

This seems to be what Red Hat considers acceptable.

In Linux terms this means that you should be able to copy /home without 
the dotfiles and a lot of /var (or /var-type things, depending on how 
you're set up) and not be surprised by the result.