* Christian T. Steigies ([EMAIL PROTECTED]) [040517 16:10]: > On Mon, May 17, 2004 at 03:35:34PM +0200, Andreas Barth wrote:
> > All I wish is that we reduce the number of source packages for the > > kernel, to ease the load for the security team. > I don't see how this reduces the load for the security team. Well, I'm not part of the security team, so my answers are not authoritative. Martin Schulz has said it, see http://lists.debian.org/debian-devel/2004/04/msg06282.html ; please read that mail for the full reasons. As I understood the security team, the number of kernel source packages just needs to be reduced. At the moment, we have e.g. kernel-source-2.4.19 testing 2.4.19-11 all source kernel-source-2.4.20 testing 2.4.20-14 all source kernel-source-2.4.21 testing 2.4.21-8 all source kernel-source-2.4.22 testing 2.4.22-7 all source kernel-source-2.4.24 testing 2.4.24-3 all source kernel-source-2.4.25 testing 2.4.25-1 all source in testing. If we manage to reduce this to two versions (one fast one, and one slow one), that would be a step forward. > I don't know if > I am allowed to say this, but nobody told me it is not ok. I built all the > recent security updates for m68k, the security team did _nothing_ for m68k. > Don't get this wrong, they patched the kernel-source or gave me patches > before the vulnerability was disclosed so I could build m68k patches and > images, but they did not build any of the m68k images, nor did they test > them AFAIK, I tested them on my m68k machines. How would one source package > reduce the load of the security team? Well, we have two issues right now: 1. kernel-source and -binary-packages are independend in their walk down to sarge, so we have sometimes just too much packages there. 2. If different archs depend on different kernel versions, it's necessary to patch more kernel-source-packages. These two issues are - as far as I can see - the main showstoppers, but our current 11 kernel-source-packages and 48 image packages are way too much. Of course, getting m68k to the fast architectures would be fun. ;) 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