Looking at how these proposed fixes would affect d-i and existing rc2
images:
a. If the SONAME is left unchanged and the new ABI remains, and things
are updated to use the new ABI:
- Installs from a rc2 netinst CD will keep working, but you'll get a
kernel with the old ABI. Installs of "third-party" (ie, alsa)
kernel modules that use the new ABI will then fail. Until you
upgrade your kernel..
- Installs from a rc2 businesscard CD will be ok.
- The rc2 netboot and floppy images will stop working once udebs
built with the new ABI reach sarge.
- We won't need to make any other changes to d-i aside from putting
those udebs in sarge and rebuilding the d-i images.
- However we won't be able to easily/widely test netboot or floppy
installs using the new ABI kernels until the udebs reach sarge.
The daily builds would need to be hacked to pull udebs from sid to
do any significant testing.
b. If the SONAME is increased and the ABI changes reverted for -1:
- All rc2 images will keep working until/unless the udebs from the -1
kernels are removed from sarge, when the netboot and floppy images will
break.
- We'll need to build new udebs for the -2 kernels, while keeping
the udebs from the -1 kernels. This will either mean some ugly
linux-kernel-di packages that build both from one package, or the
even more ugly splitting off of a linux-kernel-di-i386-2 for the
-2 kernels. Nasty nasty nasty.
- Changes will be needed in debian-cd to drop the -1 stuff from
CDs to avoid space issues.
- At the moment I think that d-i/anna will do the right thing WRT
using the -2 udebs if the -2 kernel is running. However we've
never been in this situation before, so something could fail.
- Changes will be needed in rootskel to install the -2 kernel
images. Some arches may also need base-installer changes.
- Not sure how this affects "third party" modules in debian, do they
have to build modules for both kernel SONAMEs? Do they drop -1
debs? If so rc2 gets subtly broken.
- Simply increasing the number of udebs in sarge with -2 kernel
udebs will change d-i's memory usage, which could break 20 mb
installs. I think we have a big gap before we need to worry about
32 mb installs. Still we'd need to retest everything for lowmem
again, or remove the -1 kernel udebs before the next d-i release.
I keep seeming to come up with new issues with approach b. Leaning toward
a..
--
see shy jo
Attachment:
signature.asc
Description: Digital signature