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]
