On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote: > On Wed, Mar 23, 2005 at 01:35:47AM -0800, Steve Langasek wrote: > > RC3 of Debian Installer is already being finalized, with only the CD builds > > to finish up today and tomorrow; the ABI change is being held of testing in > > the meantime. This leaves the following possible options: > > > > - Add the security fix in before sarge's release, with a change to the > > package names to reflect the ABI change. This will probably require at > > least a month to get all kernel images rebuilt and integrated into a > > debian-installer RC4 build, during which time the sarge release would be > > delayed. > How big is the possiblity that we get a new security fix during that > time that breaks the ABI again? I guess we can play this game a loooong > time... Yes, which is why I don't really want it to delay the sarge release. > > - Add the security fix in before sarge's release, without changing the > > package names. This may break some third-party kernel modules currently > > deployed on systems running testing. No one I've spoken to about this > > knows of any such modules that are definitely affected, but Andres Salomon > > has objected to this approach nevertheless. > > - Defer the update until after release, definitely with a change to the > > package names. This would be for the security team, the kernel team, and > > the d-i team to work out the details of; it would almost certainly require > > a d-i update. > How big is the chance that we will have another ABI change during > sarge's lifetime (100%?). So it can't hurd to figure out the problems > with that now independently of our decision in this matter... I would estimate the probability as approaching 1, yes. > > Since the kernel team is vetoing the idea of silently allowing this small > > ABI change through before release (which was my preference), and we don't > > want to delay the release for another round of d-i/kernel updates, that > > seems to leave a post-release security update as the only other option. Is > > this acceptable? I seem to remember that there were some ABI-changing > > updates in woody as well, and now that the kernel team is tracking ABI > > changes, they seem to be common even in security fixes; but I wanted to get > > your input first to be sure, in case you felt this needed to happen before > > release for whatever reason. > > It also seems, according to the latest emails, that the same security fix is > > going to cause an ABI change for the 2.4 kernels. Doing full updates of > > both 2.4 and 2.6 kernels before release would push my estimate out from 1 > > month to 2, based on recent experience. > My experience with the whole kernel stuff is limited so excuse the > question: Where is the bottleneck? Building the kernels, testing the > kernels or whatever else? It's a multi-stage process that currently involves making the changes to kernel-source (x2), hand-building kernel-image packages for each architecture (so the pace is set by whichever architecture's team has the least time for it), uploading all of the kernel module packages that have to be rebuilt against the new ABI, updating d-i kernel packages to match, rebuilding d-i initrds, and rebuilding CD images. For a non-ABI-changing security update, the only difference (if you want to ensure that the kernels on the CD are in full compliance with the GPL, by providing matching sources) is that you don't have kernel module packages that need to be updated, and you don't have any NEW processing to wait on. NEW processing goes quickly for such packages, but having to ask for NEW processing on 20+ source packages that are uploaded at different times spread out over a period of weeks is still tedious and introduces delays. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature