Sven Luther wrote: > Is this not the moment to modify the way our kernel .udeb packages are built, It's not a prerequisite for getting a working release of d-i for etch. I think our users are more interested in being able to install using the new kernel. > Also, i propose that we rename the kernel .udebs to use the linux- prefix, as > the .debs have done, to pave the way of futur non-linux support (hurd, *bsd or > others like opensolaris maybe). This sounds a good time to do so. I assume you mean the kernel-image udebs and not all the modules that lack any prefix. I really doubt some other OS will conflict with eg, kernel-image-2.4.27-2-386-di, and IIRC some parts of d-i have the "kernel-image" part of the name hardcoded in them, but a comprehensive patch would not be ignored. > 1) keep the sarge code as is, and use it only when installing sarge. Great, send a patch.. > 2) propose a new unified b-i/kernel code aiming at etch/sid kernels, and > using the linux-image-<flavour> thingy. > > This new code could probably just use some per-arch rules to detect flavours, > and it would even be possible in the long run to migrate that code to the main > linux kernel packages, in order keep it at one place only, also porters know > best what flavours match what subarches and so on, but we will see. If the kernel team would really like to handle issues like detecting whether an i386 machine running a UP kernel is SMP, I'd be very happy for the code for that to move there. However, I don't think the 1:1 subarch mapping you describe actually exists; it's rife with special cases. Colin already designed the code to factor out common information. > Anyway, i had a look at the "packaging overhead". Each module .udeb contains a > (rather short) control file (498 bytes for the hfs powerpc modules), a file > hierarchy, and the modules. The overhead over just the modules. The overhead > seems to be 4k per directory node, and a half k for the control file. So is > this really an overhead we are worried about. At times in addition to the ramdisk space, up to three programs (main-menu, anna, udpkg) can be running concurrently that all have to hold udeb state in memory. Care to calculate how much memory that would waste? (Make sure to take into account the memory that would have to be used to represent all the inter-module dependencies.) > The only real problem would be the number of packages issue, but if we go this > way, we could build the .udebs automatically from the kernel packages, and > then have the whole kernel build problem take only a couple of days for all > autobuilders to build the packages, and there would be no delay due to the > kernel for d-i. Alternatively, kernel team members who maintain an architecture could already take resposibility for rebuilding (and testing, which your proposal does not take into account, and without which any given kernel upload would be statistically likely to break d-i on some arch) the udebs as part of the release process for a new kernel. There's no reason for the udeb builds to lag the kernel builds by more than a day or two, and they don't for architectures that have an active maintainer already doing this (for 2.6, this is already happening pretty well for i386, sparc, powerpc, and ia64). -- see shy jo
Attachment:
signature.asc
Description: Digital signature