On Wed, Sep 14, 2005 at 08:19:16AM +0200, Sven Luther wrote: > Is this not the moment to modify the way our kernel .udeb packages are built, > and either use a single package building all .udebs or at least some common > infrastructure for building them all if there is still problems in the > archive, i feel that anything else would be unreasonable now that all arches > are built from the same source packages (except mips/mipsel, but they will be > folded in soon, i hope). > > 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. > > The next point would be for base-installer/kernel. I have thought about it > some, but me talking about that on irc faced only a huge wall of silence, so i > make the proposal here again. > > The gist of it is that : > > 1) modifying b-i/kernel will break sarge installs with the etch/sid d-i's.
It is possible to allow both kernel-image and linux-image at the same time. At least I tried to do so when I modified the sarge installer to handle linux-image-2.6.12 for amd64 a couple of months ago, although I didn't keep any kernel-image on the cd so I didn't actually test it. > 2) the kernel .debs are now built from a common package, and it doesn't > really make sense to have 12+ different code snipplet, all being subtly the > same but with individual differences in b-i/kernel. > > So, the secon proposal is to : > > 1) keep the sarge code as is, and use it only when installing sarge. > > 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. > > The last point is that i would much prefer a 1 module per .udeb solution over > the existing mess (where modules are assigned to .udebs in a rather arbitrary > fashion, which often break on non-mainstream arches/subarches). I hear this > has too much of a packaging overhead (but is this really the case ? Anyone > claiming this can argument this case with real info ?), so another solution > for the kernels could be found, where modules are not-packaged ? Well how much overhead does a package have? 500 bytes? 100? 2000? How big is the average kernel module? Looking at 2.6.12 on i386 it appears to be about 27k/module on average. What is the block size of initramfs (if it has such a concept). > 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. > > 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. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
