On 07/25/2013 05:08 AM, Nico Kadel-Garcia 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.
>

All of your points are well taken because of the way "upgrades" or 
"updates" are done -- backward compatibility simply is sacrificed.