Steve Langasek wrote: > Taking all archs together, the number of kernel udebs across all > architectures and flavours seems to be 464. If there is a limit on how many > binary packages per source the archive can handle, that probably does blow > out the limit. I thought the limit was only on the number of binaries in a > changes file, but I could be wrong. There are several limits, IIRC these include the number of packages and also the length of the binaries field that lists all the package names in the source. AFAIK they're all fixed in sarge, but that won't be useful until ftp-master is upgraded to sarge. It can also potentially break client systems that use apt-get, so we should be ok for such large sets of binary packages after sarge is released. We've bounced back and forth several times now between generating udebs as part of the kernel-image builds and as a separate step. It's more work, but I prefer doing it as a separate step. Some of the things that seem to work better this way: - d-i development frequently requires adding new modules to a udeb, or adding a new udeb, or moving modules around to free up space on an image. These changes have been frequent (one or more uploads per day) in the past. If we had to build a new kernel each time, it would be much more painful. If it had to autobuild on all arches each time, that would be excruciating. - It's sometimes been useful in transitions to make a given linux-kernel-di-arch package build udebs for two separate kernel versions. Of course we'd not release like this, but it makes it easy to test the new version while keeping the old version used for the daily builds. Once we switch an arch to the new version the udebs for the old can easily be dropped. - It can take a long time to update d-i to a new kernel version on all arches. (Granted, part of this time is spent updating the udebs.) So we often find ourselves updated to 2.4.28 on i386, while hppa is still at 2.4.27, and so on. It's useful to be able to remove the i386 2.4.27 udebs at this point, to avoid them shipping on the CD images and increasing the installer's memory and bandwidth requirements (from Packages file entries). If i386 and hppa or other arches had udebs built from the same kernel-source then we'd not be able to remove them until all arches were updated. - d-i contains a document on using a custom kernel. A user building a custom kernel may not want to base it on the kernel-source package, so having the linux-kernel-di-i386 as a separate package that they can use to split up a kernel-image.deb they created by their preferred means adds flexability. -- see shy jo
Attachment:
signature.asc
Description: Digital signature