On Monday, November 07, 2011 07:00:08 PM you wrote:
> On Mon, Nov 7, 2011 at 2:02 PM, Connie Sieh <[log in to unmask]> 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.