On Mon, May 19, 2003 at 09:33:48AM +1000, Brian May wrote:
> Looking at woody in fact, it appears to only exceptions appear to be
> HPPA and IA64:
>
> kernel-source-2.2.22 - Linux kernel source for version 2.2.22
> kernel-source-2.4.10 - Linux kernel source for version 2.4.10
> kernel-source-2.4.14 - Linux kernel source for version 2.4.14
> kernel-source-2.4.16 - Linux kernel source for version 2.4.16
> kernel-source-2.4.17 - Linux kernel source for version 2.4.17
> kernel-source-2.4.17-hppa - Linux kernel source for version 2.4.17 on HPPA
> kernel-source-2.4.17-ia64 - Linux kernel source for version 2.4.17 on IA-64
> kernel-source-2.4.18 - Linux kernel source for version 2.4.18
> kernel-source-2.4.18-hppa - Linux kernel source for version 2.4.18 on HPPA
> kernel-source-2.4.19 - Linux kernel source for version 2.4.19
> kernel-source-2.4.20 - Linux kernel source for version 2.4.20 with Debian
> patches
2.2.22 has i386-{compact,idepci} and some alpha kernel images
2.4.10 has no reason to even be in the archive as far as I can tell
2.4.14 has an associated m68k patch, but no kernel images
2.4.16 has i386 and ARM kernel images
2.4.17 has powerpc, hppa, ia64, mips and mipsel kernel images
2.4.18 has i386, alpha, hppa, powerpc, and sparc kernel images
2.4.19 has mips and sun4u kernel images
2.4.20 did not ship with woody
We could practically shrink woody by one CD if we could consolidate some of
these.
In addition, we have:
kernel-image-2.2.10-apus | 2.2.10-13 | stable | powerpc
kernel-image-2.2.10-powerpc-apus | 2.2.10-13 | stable | source
kernel-image-2.2.19-netwinder | 20011109.1 | stable | source, arm
kernel-image-2.2.19-riscpc | 20011109 | stable | source, arm
kernel-image-2.2.20 | 2.2.20-5 | stable | i386
kernel-image-2.2.20-amiga | 2.2.20-2 | stable | source, m68k
kernel-image-2.2.20-atari | 2.2.20-1 | stable | source, m68k
kernel-image-2.2.20-bvme6000 | 2.2.20-1 | stable | source, m68k
kernel-image-2.2.20-chrp | 2.2.20-3 | stable | powerpc
kernel-image-2.2.20-compact | 2.2.20-5 | stable | i386
kernel-image-2.2.20-i386 | 2.2.20-5 | stable | source
kernel-image-2.2.20-idepci | 2.2.20-5 | stable | i386
kernel-image-2.2.20-mac | 2.2.20-1 | stable | source, m68k
kernel-image-2.2.20-mvme147 | 2.2.20-1 | stable | source, m68k
kernel-image-2.2.20-mvme16x | 2.2.20-1 | stable | source, m68k
kernel-image-2.2.20-pmac | 2.2.20-3 | stable | powerpc
kernel-image-2.2.20-prep | 2.2.20-3 | stable | powerpc
kernel-image-2.2.20-reiserfs | 2.2.20-4 | stable | i386
kernel-image-2.2.20-reiserfs-i386 | 2.2.20-4 | stable | source
kernel-image-2.2.20-sun4cdm | 9 | stable | sparc
kernel-image-2.2.20-sun4dm-smp | 9 | stable | sparc
kernel-image-2.2.20-sun4u | 9 | stable | sparc
kernel-image-2.2.20-sun4u-smp | 9 | stable | sparc
for which there is no corresponding kernel-source in woody. This means that
these kernels cannot be built on woody, and this is very problematic for
support (specifically security fixes). There seem to be about 85
kernel-image packages in woody, and I have no idea how many of them can
actually be built, much less patched and supported in any sane way.
To fix the ptrace bug, the s390 and mips architectures rolled the ptrace
security fix into kernel-patch-2.4.17-s390 and
kernel-patch-2.4.{17,19}-mips. This makes things even worse, because if
kernel-source-2.4.{17,19} are patched to contain the fix, it will almost
certainly make these architectures' kernel images fail to build because of
patch conflicts, and require that the -patch packages be updated _again_ to
undo this.
> user-mode-linux builds by depending on "kernel-source-2.4.20" and
> automatically applying the UML patch, I wonder if the same thing could
> also be doine for -hppa and/or -ia64?
UML doesn't build a kernel-source package at all; it works essentially like
kernel-image-x.y.z-i386. That is, it build-depends on kernel-source-x.y.z
and kernel-patch-uml, and builds with those.
This approach has its share of problems, of course. In fact, to use UML as
an example again, I believe user-mode-linux will not build in woody because
it build-depends on the exact version of kernel-patch-uml that it expects,
and 'testing' apparently does not care about build-dependencies.
The ideal solution would be to be able to share tarballs between source
packages. Then, all of the kernel-image packages could be built as if they
had a complete kernel source tree as their source package (which simplifies
things a lot), and yet we would only need one such tarball in the archive.
Of course, I have little idea how much work this would be to implement,
except that it would touch a lot of different tools. I don't have the time
anyway.
Making 'testing' aware of build-dependencies seems like it should be
significantly more straightforward, and if we are stuck with this
source-as-binary hack for the time being, it may as well be able to work
correctly.
--
- mdz
