* Joey Hess ([EMAIL PROTECTED]) [050325 17:05]:
> Andreas Barth wrote:
> > [What changes to d-i need to be done for a security upload?]
> Besides building the udebs, if the abi changes we have to update rootskel,
> base-installer, and the debian-installer build system.
>> [...]
> Not quite accurate, it really tries to install the specific kernel version
> that was hardcoded into it at build time. Even arches with metapackages need
> this to be updates since the metapackages are not available on all media.
> For sarge, the info is unfortunatly harcdoed in two places; some of it
> is in rootskel and some in base-installer.
> > 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.
> A point release that introduced a new kernel abi would break old
> businesscard cds, since those have the udebs that expect the old kernel,
> but downloads the kernel from the archive. Unless we kept the old kernels
> in the archive of course.
>
> Something you left out is that when the kernel abi is changed, debian-cd
> may also need to be changed, to exclude the kernels for the old abi (if
> those are left in the archive) and to include the new kernels. Depending
> on the CD build process, the inclusion of new kernels may be done
> automatically (there's a script that updates the list), but exclusion of
> old kernels will not, and it can fill up CDs.
Ok, summarising this means for me:
If we change the abi for d-i, than a lot of work at a lot of places
needs to be done. Definitly possible, but not the thing we want to do
for each security upgrade. On the other side, as long as we keep the
old kernel around, and don't rebuild the CDs, everything is still fine.
The reason why we cannot keep the old kernels was - beside the fact that
it's not so nice if we force our users to upgrade their kernel as first
action - that we're overwriting the kernel source with the upgrade.
However, as long as the updated kernels are only available via
security.d.o and via {stable,testing}-proposed-updates, the overwriting
doesn't happen.
So, one idea would be to push the updated kernels into sarge only very
seldom (means: reserve time for exactly one more ABI transition in
sarge before release, rest happens only in unstable, t-p-u and/or
testing-security), and decide on each of the following point releases
whether we want to have the effort to touch all of the mentioned
packages, or if we keep the updated kernels only on security.d.o.
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]
