Upgrading from way back (was Re: The fate of libc5)
On Tue, 11 Jul 2000, Ben Collins wrote:
> > The talk about 'limit upgradability to two major releases back' gives me the creeps!!
> > It would be very sad if we did this... Yes, it will make the releases take longer, but
> > some people seem to forget that Debian GNU/Linux is _NOT_ about fast releases, we
> > are about _QUALITY_!!! Debian have always been the _BEST_ (!!!) UNIXLikeOperatingSystem
> > (tm) there've been. One of the reason for this (at least in my NOT so humble opinion :)
> > is that we take TIME to test, test, test (etc) over and over again, so that what we
> > release officially, WORKS. And works GOOD, SECURELY and STABLE!!!
>
> Show me a developer who can guarantee bug free upgrades from "bo" to
You fundamentally can't guarantee bug-freeness in anything larger than hello.c
_ever_. Even in hello.o you can't because the compiler is too big.
> "potato". I don't think you will find one single person who can. The easiest
> way to do it would be to upgrade to hamm, then to go to potato (and
> probably still have to go to slink inbetween). This isn't about limiting
> something we already have. Currently no one can test whether we really do
> support upgrades that far back, so why not emphasize it?
You are wrong here. We do support upgrades from bo directly to potato, and
(among others) Philip Charles did a great job to test it (see e.g.
http://www.debian.org/Lists-Archives/debian-cd-0005/msg00295.html). The
release notes (dists/potato/upgrade-*) include all needed information.
The easiest way is to go directly from bo to potato. You forget that "stepped"
upgrades require either massive downloads from archive.d.o or CDs that aren't
readily available any more.
Note however, that the release notes clearly state that only _one_-level
upgrades are "officially supported". But we _do_ describe the easiest=one-step
way of upgrading from earlier releases just to stress that it is _possible_.
And we specifically state that backups should be made before _any_ upgrade, so
people should be able to restore the original situation even when an
"officially supported" upgrade goes wrong.
I suspect that this kind of "upgrades from way back" will continue to be
possible, as long as people continue to make good use of the various control
fields.
However, I'm no libraries expert, so I wouldn't know if a libc5 package from
bo can coexist with a glibc2.x from woody, in the potential case that libc5
would be removed from woody.
Regards,
Anne Bezemer
Reply to: