Re: linux-kernel-di udebs [Was: Re: 2.6.12 upload]

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Jul 28, 2005 at 06:18:28PM +0200, Goswin von Brederlow wrote:
> Bastian Blank <waldi@debian.org> 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