On Wed, Nov 9, 2011 at 8:05 PM, Tom H <[log in to unmask]> wrote:

>> 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.
>
> I'd forgotten about "upgradeany" (probably because I've never used
> it). AFAIU, it's useful if the installer cannot recognize your
> installation as upgradable because of a modified/broken
> "/etc/*-release". So it's just a special case of "upgrade".

If you *paid for a license*, you could get business grade support. As
it is, you're stuck with experienced and possibly even more expert
help such as the folks on this list, but most of us have day jobs.

Should you or others decide to upgrade from SL 5.x to SL 6.x, I also
recommend a dirty trick that will make the job faster. If you're
running an x86_64 architecture, use "yum remove" all pachages that are
".x86_64" or ".noarch" or the GPG keys, wich are "none". SL 6.x by
default installs only the most appropriate packages for your
architecture. SL 5.x and older releases tended to install *both*,
which is partly why there is "/usr/lib" and "/usr/lib64" and other
parallel installation locations. It's also why a lot of packages can
be awward to install from 3rdparty repositories that contain only
*one* architecture in one yum repo. This used to drive me *nuts* with
tools like Subversion, because "yum install subersion
--enablerepo=rpmforge" would try install the more recent rpmforge
package for my 64-bit host, but would also try to install the 32-bit
version from my main OS repository.

Hilarity would ensue.

> I was hoping for a "preupgrade" option for an SL6-to-SL7 upgrade not
> an SL5-to-SL6 one because "preupgrade" appeared in F10 or F11 and
> SL6's based on F12/F13.

It works well *from installation media*, which have additional
information about the renaming of components. Between SL 5 and SL 6,
for example, kde4 was added and is in parallel with kde3.  The "samba"
and "samba3x" packages, or "openldap" and "openldap24", take some
extra processing to handle when updating. And when the breakdown of
packages into multiple components change, adventure can ensue.

> You're probably right that "preupgrade" might not be able to handle as
> large a jump as SL6 to SL7.

We'll wind up seeing. SL5 to SL6 was basically a 4 year jump, because
our favorite upstream vendor took a *long* time to make their version
6 release.

>> 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.
>
> You can add "%pre" and/or "%post" scripts requiring user-interaction
> to an SRPM's spec file and package/repackage an RPM but it's very much
> frowned upon. You won't get a "nice" debconf dialog but you can
> _PROBABLY_ so the same thing.

If I caught you doing it in a package I worked with or supported, I'd
get cross. One might check for the presence of a 'tty' and act
accordingly, but RPM updates are really supposed to be unattended.

Mind you, I do like the various 'dpkg-reconfigure' tools from our
Debian friends, the "reset the MySQL admin password" and "configure
smarthost behavior for your mail server". Someone spent a lot of time
making those work well.

> (I've forgotten how to do so but you can set up apt to answer debconf
> dialogs automatically.)
>
>
>> 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.
>
> I've had problems with various types of upgrades whether using Linux
> or Windows/OS X. My latest misadventure was upgrading my iPad from iOS
> 4 to iOS 5... But, thankfully, the majority of the upgrades that I've
> attempted have been successful. I prefer clean installs though!

Heh. I've tended to be the poor bugger who gets to test them out and
work out the kinks. It's why I try to *always* have the leading edge
versions on at least one host, so I can see the problems coming down
the pike. (And I'm very grateful for Scientific Linux's quick release
of SL 6.1, for just such testing.)