Hi,
this mail consists of two parts: First, I describe my understanding of how
any kernel upgrade currently works. Please feel free to cluebat me if I
got it wrong. After that, I list some ideas how we can minimize the amount
of work for the security team once sarge is hard frozen, and the round trip
time. Also, this mail is just targeted at our sarge behaviour; I know
there are further plans for etch.
The upgrade starts with uploading a new kernel-source-2.{4.27,6.8}-package.
This package contains the binary packages needed as build-dependencies for
the individual kernel images.
After this package is accepted (or available via other means), for each
arch the appropriate arch-specific source package (like
kernel-image-2.6.8-i386) is rebuild (and the build-dependencies are
tighted so that it need to take the new build-dependencies). This source
package also produces one binary package per subarch that is used for
creation of the d-i packages, e.g. kernel-image-2.6.8-2-386. Now, the d-i
arch-specific source package (like linux-kernel-di-i386-2.6.8) needs to be
rebuild. For some archs (like s390), the (normal) kernel package and the
kernel patch are two source packages, so that first the arch-specific
patch needs to be rebuild.
If an ABI-change happens, all binary-packages have to change name.
Currently, there are no tools for that - but of course, that might be
changed, given how many packages we have.
Also, after an ABI-change, all depending kernel-modules like
alsa-modules-i386 have to be rebuild, with tighted build-dependencies. It
need to be checked that actually all modules in sarge are able to do this,
the others may be considered as already RC-buggy.
[What changes to d-i need to be done for a security upload?]
The d-i changes are only finalized with the next point release - but well,
that doesn't usually matter (except if there is remote root by a kernel
bug), as the kernel images and source is pushed to sarge with the point
release.
However, there is one issue with d-i: The installer decides which kernel
image to install in a bit arch-specific way. On the architectures without
a meta-package, the installer can only install the same kernel image as the
udebs were built from. This is actually still possible to live with, as
the kernel images will be available till the next pointrelease, but that
means that users get an unsecure kernel installed by default on that
platforms, and that every point release breaks the installer CDs on that
platforms.
One idea how to handle this is:
- Write scripts that make the necessary changes to the source packages, so
that adjusting the source packages for a security update is not more
effort than running one script. The script should be able to optionally
make the changes for an ABI-change.
- Allow source-only uploads on security, so that the security team is not
forced to hand-build on each arch.
With that, a security upload would go:
- Fix the common source package, and upload it.
- Run the script, make a test-compilation of one arch-package, and upload
all basic arch packages (source-only), wait till the binary packages are
there.
- Test an appropriate number of kernels
- Upload the d-i-kernels, wait till they're built.
- rebuild all modules.
Comments on these ideas are appreciated. Also, if the ideas are basically
ok, it might be a good idea to freeze the 2.4.27 and 2.6.8 packages, and
any updates should go through the hands of the security team, in
cooperation with one designated person from the kernel team and perhaps one
person from the release team.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
