[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sarge?



On Sun, May 02, 2004 at 07:06:49PM -0400, Carl Fink wrote:
> On Sun, May 02, 2004 at 10:11:35PM +0100, Colin Watson wrote:
> > It took quite a bit of effort (several months and a complete cessation
> > of work on the new debian-installer) to whip the potato installation
> > system into shape for woody. Sadly, we have *not* historically been in a
> > position where we can just drop in the installer from the previous
> > release and expect it to work, and by the end of its life boot-floppies
> > was such a nightmare to develop that this *was* a major blocker. A
> > substantial part of the point in investing so much development effort in
> > d-i is to fix this perennial problem for the future.
> 
> Fair enough.  I have only written installers for applications, not operating
> systems, so I'm quite ignorant of these issues.  Could you clarify why the
> Woody installers can't install Sarge?

I was never a boot-floppies developer, just an observer, but:
debootstrap update (fairly trivial, but needs to be done). Lack of
support for newer kernels, particularly on non-i386 (big task); you
don't really want to run sarge on 2.2 and the security team don't want
to support 2.2 any more. Changes in the base system have a
well-documented habit of breaking the installer, which in turn takes
time to fix. I'm guessing, but it wouldn't surprise me if the
interaction with the second stage has changed. CD building issues.
Probably architecture-specific issues I don't know about.

Of course, woody had a somewhat harder time of it because it added
several new architectures, but the only reason that hasn't happened for
sarge is because changes need to be made in the archive maintenance
system first, and the timeframe for that couldn't have been predicted at
the beginning of the sarge release cycle.

Let's go on a tour through the woody development cycle:

  http://lists.debian.org/debian-devel-announce/2000/debian-devel-announce-200012/msg00012.html

    giving up on d-i development as taking too long, returning to then
    non-functional b-f

  http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200102/msg00014.html

    "Short summary: It's about time we froze. Go help Adam with
    boot-floppies." i386 boot-floppies not working yet.

  http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200104/msg00004.html

    "In short: there hasn't been any [progress], go help Adam and David
    with boot-floppies." Still no working i386 b-f.

  http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200105/msg00003.html

    One successful i386 install with "CVS versions of this and hacked
    versions of that".

  http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200106/msg00014.html

    b-f finally more or less OK enough on some architectures to start a
    freeze process.

  http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200107/msg00011.html

    alpha, mips, mipsel, s390 (and others that didn't release) still
    didn't have working installers. Note that alpha was supported in
    potato.

  http://lists.debian.org/debian-devel-announce/2001/debian-devel-announce-200108/msg00002.html

    Ditto.

After that things more or less got sorted out. Of course, the woody
freeze then got sidetracked by crypto-in-main and the suddenly
discovered need for a major upgrade to the security build
infrastructure, but that's another story. Still, that's five months from
ground zero to an install that worked at all for one developer with
weird hacks on i386, six months to something reasonable on a few
architectures, and over eight months to something we could even think
about releasing. If you're trying to freeze six months after release,
that frankly sucks. Going that route for sarge just wasn't an option
with elderly code with that kind of track record.

Sure, we've had to take the hit of a massive initial development cycle
for d-i, but it's now got considerably more developer interest than b-f
ever had, it has a distributed maintenance structure so it's possible
for more than a few gurus to manage to build and upload the thing
correctly, it uses our autobuilder infrastructure so supporting other
architectures is considerably easier, and it makes use of micro-packages
generated as part of regular uploads of packages in the main
distribution to unstable to reduce the duplication of effort involved.
With some forthcoming debootstrap changes, we stand quite a good chance
of being able to maintain a rolling installer for testing for at least
some of the time from here on in. There are still problems, but the
light at the end of the tunnel is generally visible and distinguishable
from oncoming trains.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: