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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]