On Wed, Sep 14, 2005 at 03:28:30PM +0200, Sven Luther wrote: > not sure i fully understand what you mean here. I guess you are saying you can > kind of fix the b-i/kernel rules to install either linux-image or > kernel-image, but that would be counter productive, now that we have some nice > unified packages, we can have a simple set of rules for all arches, and make > the code much more maitenable.
Well is 2.4 kernel images being dropped from etch? Are the archs that still use 2.4 going to update their images to be linux-image-2.4.x? Unified rules sure sound nice. > Also, keep in mind that some of the flavours changed between the new packages > and the old stuff. Well some like -586 seem to have disappeared if I remember correctly. > We don't care about initramfs, because the modules which go into the initramfs > are already unpacked, and there is thus no overhead, the overhead can only be > concerning : Ah, good point. > 1) the archive space used up on the mirrors. So the overhead of 1000+ potential modules (although wouldn't some of them like sound be worth stripping out as irrelevant to the installer?) > 2) the space used up on the cd medias. At 2k blocks, 1000 modules would probably add an extra 1M of wasted block space (assuming each wastes 1/2 of 2K each). Probably not a big deal really. Well plus any overhead from the package header and potential loss of compression due to a smaller amount of data to work on in each package. > 3) the actual download size of the .udebs. On the other hand, what if you didn't have to download as many? Would the installer be able to save ram by not having to load unnecesary modules? > 4) maybe the time it takes to process the Packages file on slower arches, > and the effect .udeb multiplication has on this. That could be annoying. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
