On Thu, Jul 25, 2013 at 8:08 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Thu, Jul 25, 2013 at 5:28 AM, Tom H <[log in to unmask]> wrote:
>> On Thu, Jul 25, 2013 at 1:28 AM, David G.Miller <[log in to unmask]> wrote:
>>>
>>> I'm guessing you could back-port FedUp to EL and have a reasonable shot at
>>> upgrading EL-n to EL-n+1. I wouldn't want to guarantee that an arbitrarily
>>> complex installation will work though and the people who really want to
>>> upgrade are those with really complex systems that they don't want to have
>>> to re-create from a clean installation. So we end up stuck with the
>>> contradiction that simple installations could probably be upgraded but the
>>> complex installations that people really want to upgrade can't.
>>
>> If you package and script your configuration, there's no such thing as
>> a complex system.
>
> Your faith in the ability of scripting to read human minds seems to be
> boundless. Mine.... is far lower.
>
> For example, simply updating Subversion from one version to another is
> irreversible: all the working copies checked out with Subversion 1.4
> (from Scientific Linux 4) to Subversion 1.6.11 (the current copy in
> Scientific Linux 6) get updated when used, and are no longer
> compatible with the older Subversion 1.4 client. If you have a home
> directory that will still be used with SL 4 operating systems in the
> same work environment, it's a *big* problem. Similar problems occur
> with locally compiled packages that were written to require versions
> of Python or gcc that are no longer availalbe in the new OS. And you
> would not *believe* the number of packages I've had to help rebundle
> in the last 5 years because the authors were unable, or unwilling, to
> et off Apache 1.3 and I had to help switch their base OS to something
> still supported.

I've been spoilt by working in a large environment with dev, uat, and
prod boxes where roll-outs/installs/patches/upgrades are tested
extensively before moving to prod and a subversion-type problem would
be caught and dealt early on. Anyway, developers cannot maintain
backward compatibility on a permanent and eternal basis; it
complicates and slows down development and testing.

I also hear you about legacy stuff. Until two years ago we had a few
Solaris 2.5.1 installs (EOLd in 2005 and still have one instance of
2.6 in production, EOLd in 2006) because they were running an
application whose developer team didn't want to dedicate any time to
upgrade (rewrite?) for a more recent version of Solaris or Linux. It
was a headache in more ways than one. Sun makes a bundle when we keep
legacy stuff around - and Red Hat will also if we ever keep an older
EL around because we won't upgrade to a newer one and mess around to
get an application to work on it. In these cases, it all comes down to
willingness and ability to pay.