John Smith wrote: > -d-i etch is (rightly) a continuation of d-i sarge, but the > udeb's used in the installation are not kept seperatedly on the mirrors. > d-i-sarge uses d-i-etch udebs. That's incorrect. Like any other package in debian, a udeb is kept at different versions in each branch of debian. For example: base-installer | 1.13.4 | stable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc base-installer | 1.39 | testing | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc base-installer | 1.39 | unstable | alpha, hurd-i386, m68k base-installer | 1.40 | unstable | source, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc > -there isn't a process to do maintenance (debug errors) on sarge > only udebs. That's incorrect. If a serious bug is found in any package in stable, it can be corrected in the next point release. d-i udebs are just packages. For example, we've been talking with the security people about issuing an update for the topmost errata item listed at http://www.us.debian.org/releases/sarge/debian-installer/ With that said, like any other package in stable, most bug fixes will not warrant an update to stable; it's generally more important that stable be unchanging and bugfixes have a way of leading to other problems. Most of the errata items would be good candiates to be fixed, if someone wants to do the work. > Keep in mind there never was an official d-i-sarge. The one > downloadable from March '05 is still marked as rc3. That's incorrect and is as absurd as claiming that Debian never released an official kernel or libc with sarge because we didn't rebuild the whole archive that day. That's not how things work. Just because we called it "rc3" (which, by the way, stands for "release candidate") when it was released and, there happens to be a symlink to that effect in the archive, does not make it not be the official sarge installer, built with the procedures we established to build the official sarge installer, and tested with the quality control measures we set down for the sarge installer. Part of that quality control involved testing it or a month or more, and it had no bugs serious enough to warrant another round of updates to the boot images show up in the remaining months before the release. (We actually did slip in a few fixes to individual udebs after rc3, including a crucial fix made just days before sarge's release, but nobody noticed them.) > I use the one from JoeyH's images dated 6-6, the release date of sarge. Which is some random snaphot of when post sarge development was just beginning again, that was built on a machine that had been running something newer than sarge for several months, using build parameters that did not target the images at installing stable (iirc those images will pull d-i udebs from testing like any other d-i daily build), at a period when my maintainence of it was very low due to being marooned at the beach, but whatever. > D-i-etch isn't backwards compatible with sarge (ie. not able to > install sarge, see 344371). Correct. If anyone feels like implementing this, we will accept it, just as we did when the debian-edu developers made sure that the sarge installer would install woody. But in the meantime maintaining compatability with sarge would be a lot of work and a severe limit on the numerous large improvements we have been making since the sarge release. -- see shy jo
Attachment:
signature.asc
Description: Digital signature