EOL of Warty?

[Alan McKinnon]

On Friday 24 March 2006 13:34, Colin Watson wrote:

<snip>

> Even after reading your post, I'm not really all that sure of the
> difference. :-) The nearest precise definitions of those terms are
> apt's, where "update" means "update the package indices" and
> upgrade means "fetch and install new packages". An update every six
> months in these terms is not terribly useful, so I assumed you must
> simply mean "fetch and install new packages", which I call
> "upgrade".
>
> Is the distinction you're drawing one between applying security
> updates and upgrading to the next release?

Yes, that's how I use the terms. 

Ubuntu and apt may have subtle differences in how the terms are used 
so it's best we define accurately what we mean.

> > The GGP mentioned infrequent updates on his wife's machine, I
> > responded that it's not unreasonable to expect him to do updates
> > maximally six months apart, so that doing an upgrade (if he wants
> > to) to the next OS is relatively easy.
>
> I do still somewhat disagree here. While it's true that we expect
> and hope for people to apply security updates reasonably
> frequently, we have an awareness that in many environments it is
> not sensible to upgrade from release to release every six months;
> for instance, installations in schools would not want to upgrade in
> the middle of the school year, and in office environments there
> will often be a long test and deployment cycle. While the actual
> physical process of upgrading from release to release isn't too
> much work, it may well take inexperienced users some adjustment to
> cope with the changes on the desktop, and so I can quite understand
> that even home users might well not want to go through a mental
> gear-shift every six months.

I see what you mean. The common solution in the industry is upgrades 
every x years, which makes that problem go away entirely. A 6 month 
release cycle has definite advantages, but also problems of it's own, 
like skipping releases when upgrading.

How would you cope with very deep changes? Like (contrived example):

Upgrade distro A to distro D, skipping B and C.
B upgraded glibc, and D upgraded it again.
Some packages in D are unchanged from C and require the glibc present 
since B; while other packages in D require the new glibc from D?

Even simple things like gnome dropping fam in favour of gamin can 
wreak havoc if the jump is big.

<snip>

> To be honest, the chief reason that upgrades from very old releases
> don't work is that every so often a developer wonders why some bit
> of compatibility cruft is there, realises it's to cope with
> something three releases ago, and gets rid of it. :-)

Ah, that makes sense. Been there, done that.

-- 
Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five