On Thu, Jul 28, 2005 at 06:18:28PM +0200, Goswin von Brederlow wrote: > Bastian Blank <[EMAIL PROTECTED]> writes: > > > On Thu, Jul 28, 2005 at 04:49:01PM +0900, Horms wrote: > >> I tend to aggree, though I believe Franz Pop, or perhaps some of the > >> other d-i team members have reason for keeping these images separate. > >> Perhaps they could reiterate them here. > > > > Mostly two reasons: > > - Changes in the d-i packages don't trigger a complete rebuild. > > - There are more then 200 different binary packages. > > > > Bastian > > At the start changes have been common and modules have been added or > removed or packages been split or joined. > > But hasn't that settled down now? Aren't the linux-kernel-di udebs > consistent enough to be handled by kernel-source uploads? > > I've CCed debian-boot to get a broader opinion.
Notice that i believe this is a bogus argument anyway. The right way to solve this would be for the main kernel package to provide one .udeb for each individual module, and then the problem of regrouping them or not and changing sizes goes away all by itself. And we even gain flexibility at the d-i image build level, and make third-party (particularly non-free modules) .udeb inclusion easier. We would not be limited to the actual artificial and sometime bogus grouping and separation of .udebs, and we would have the possibility to download only those drivers we need. If all other technical aspects are solved (more to this below), this would be the most clean and elegant solution. Sadly, it seems that the dpkg/apt/whatever infrastructure will have some trouble keeping up with the *HUGE* amount of .udebs involved, and this was probably the reason why this was not done for the sarge timeframe, especially as we where in the "we will release next month" loop. But now we are at the start of a new release cycle, and there should be no major reason not to solve this technical huge-number-of-udebs problem in our infrastructure. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
