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.
