On Monday, November 07, 2011 07:00:08 PM you wrote:
> On Mon, Nov 7, 2011 at 2:02 PM, Connie Sieh <[email protected]> wrote:
> > Yes that is our support stance. It is NOT supported by either TUV or SL .
> I remember that thread and Connie's response. I'm sorry that I
> suggested in this thread that it was OK; I was confusing RHEL/SL with
> Fedora, where it is OK and one of the Anaconda pre-release QA tests.
Not supported != doesn't work. Which means, if you get it to work, that's
great, but if it fails to work, you get to keep the pieces, and you won't be
'entitled' to any sympathy or help.
There has been an 'upgradeany' command line option in CentOS at least for
several cycles, but it is also not supported. It might work, but it likely
will leave your system in a 'self-supported' state. Meaning, again, that when
it breaks you won't get any sympathy, and you'll likely get the 'unsympathy'
which seems to be typical for techie lists.... sorry, but facts are facts, and
whether it's right and fair or not, it just *is* the case.
Likewise, preupgrade tends to work fairly well for Fedora; but when it works it
typically doesn't work for an upgrade increment of more than two Fedora
versions. The Fedora version skew between EL5, based somewhat on FC6, and EL6,
based somewhat on a melange of F12, F13, and other things, is 6 full Fedora
versions. Even if preupgrade were available for FC6, it likely would not
upgrade to F12 even in one step. It's not likely to be ever be *supported* on
EL of any version, even if it does become available.
This is where the one of the major differences between the RPM packaging and
the DEB packaging shows itself. Debian (and Debian-derivatives) take advantage
of the possibility of interactive response in a DEB to deal with real upgrade
issues; RPMs are not supposed to do any interaction with the user in any of the
package's scriptlets. The DEB scripts have wide latitude in what they can do,
and have several powerful tools available for use in the script. It does make
complete unattended upgrading somewhat difficult, as it prompts the user for
lots and lots of things and seemingly random times; IOW, it's not a 'start it
and let it run overnight' thing without effort.
I've attempted preupgrade upgrades, and have not had one go 100% successfully
yet. Nor, for that matter, have I ever had a DVD or CD upgrade of any Fedora
version go 100% successfully, either.
So I typically 'upgrade' by keeping a separate /home and backing up everything
in /etc and /var that will be needed in the new version (I of course back up
/home as a matter of course), and getting a 'versionless' RPM listing ( rpm -qa
--queryformat="%{NAME}\n"|sort ). If anything is in /usr/local or /opt those
get backed up, too, and separately evaluated. For workstations it's not too
hard; servers are another matter. I then do a fresh installation, making sure
to neither format nor mount the old /home.
I'll retrieve the package listing and the repository info (being in
/etc/yum.repos.d, it gets backed up with /etc) and check those to make sure the
repos and options are the same, and then I'll enable those repos, do an initial
yum update, and then use the yum-utils program repoquery to get a full listing
of all packages that are available, use diff in a creative manner, and do other
manual things to get a valid list of packages to install, and pass that list to
yum.
Once I'm satisfied all the packages my /home are going to need are installed
properly, I'll read the release notes both of the distribution and of the major
upstream packages I use (things like, GNOME and KDE, Ardour, JACK, and those
other things I use on a daily basis) and make sure there's not going to be
major reshuffling or data corruption or improper operation in those programs'
configuration directories in my /home.
I'll test with a normal user named the same as my main user ID before
remounting my /home, and make sure things look reasonable with copies of what
that program needs from my /home (mounted somewhere else, of course), and once
that looks good I'll reboot in single user mode, rename /home to /new-home,
recreate the /home mount point, and set /etc/fstab to mount /home again. I'll
also set up an selinux relabel for the entire filesystem (I do, unlike most,
run my workstation with SELinux ON and ENFORCING).
And those release notes things and checking should be done even if you do a
preupgrade-sort of thing, or a string of yum updates with repo files pointing
to various places.
It is more of a pain for a user to do the upgrade the way I do upgrades, but
the fact of the matter is that the current RPM system simply is not built to do
robust upgrades when many upstream packages have major differences between
versions, in terms of data files and configuration; the scriptlets just don't
have enough power at their disposal, really, and especially in the anaconda
chroot used during media-based upgrades as well as preupgrades (which are still
media-based, to a degree). And without being able to query the user and use
those answers in the upgrade environment, it's probably a good thing the
scriptlets are limited in how much they can do, since the default action chosen
by the packager is guaranteed to be the wrong thing to do for some user
somewhere.
Upgrades are hard (even in Debian, been there, done that). They're hard
primarily because the upstream packages in many cases don't consider easy user
upgrades a priority, or they don't have the resources to do everything a
seamless upgrade requires. But secondarily packaging systems in the typical
RPM-based Linux distribution don't give packagers the tools to make it easy for
the user doing the upgrade. And the scripts in a DEB often don't have the
exact option you want, and they are annoying when you're taking the default on
all but one specific package.....
At least the upgrade paths do get tested and maintained in Debian; it's my
opinion that's one reason for their long release cycles. The upgrade paths
available with a yum-based upgrade aren't well tested (and may not be
maintained, even), and even those who have done them (and I've done them with
older RPM distributions, in particular Aurora SPARC Linux going between
versions where installing the old version with media and yum upgrading to the
latest *was the normal way of getting the latest version* ) haven't tested your
specific upgrade path!
So caveat upgrador, to use bad Latin. And forget ala carte upgrades (kernel
only, or KDE only) unless you want to roll your own.
