Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 02:31:41AM -0800, Steve Langasek wrote:
> On Tue, Nov 30, 2004 at 10:40:24AM +0100, Sven Luther wrote:
> > > You don't generate udebs for each flavour because there
> > > is not necessarely the need for it. In the i386 example there is only
> > > one set of udebs coming from the -386- flavour.
>
> > Well, maybe, i am no expert on x86, but on powerpc, you need one set of
> > modules for each flavour, since they are using incompatible instruction set
> > optimization : powerpc (everything from 601 to the G4, passing by some
> > embedded processors), power3 (used in ibm rs6k, 64bit and more of a power than
> > powerpc processor), and power4/g4.
>
> > > | Like waldi said, it was around 200 packages 6 month ago, and
> > > | probably over 400 today,
> > >
> > > My request of being in CC has been ignored and I lost part of the
> > > messages.
>
> > Ah, missed that also. like said a current calulation brings a total of 739
> > .udebs in all the debian kernel packages. Maybe some of it is overkill given
> > the small number of .udebs ubuntu has. Maybe you can have some insight here ?
>
> > > Or for example you don't need k7 udebs, since the 386 will do.
>
> > Sure, but this is because on x86 the flavours are mostly only different
> > optimization, but on other arches this is not the case. I believe that on
> > powerpc, m68k, mips/mipsel and arm at least, the different kernels are there
> > because of real incompatibilities, maybe for other this is the case also. We
> > speak more of subarches than flavours here really.
>
> > > There are clearly exceptions like ppc that needs more.. i don't disagree
> > > and i did never questioned this situation.
>
> > I believe that x86 is the exception here, while the other arches situation is
> > the norm, and even on x86, if you think about pure64, and 386/486 situation,
> > you would reconsider this, but then ubuntu probably don't care about such old
> > x86 hardware, and rightly so.
>
> alpha -- 1 subarch -- 29 kernel udebs => 28 udebs / subarch
> arm -- 5 subarchs -- 28 udebs => 5-6 udebs / subarch
> hppa -- 1 subarch -- 8 udebs => 8 udebs / subarch
> i386 -- 2 subarchs -- 81 udebs => 40-41 udebs /subarch
> ia64 -- 1 subarch -- 24 udebs => 24 udebs / subarch
> m68k -- 7 subarchs -- 67 udebs => 9-10 udebs / subarch
> mips -- 3 subarchs -- 29 udebs => 9-10 udebs / subarch
> mipsel -- 4 subarchs -- 37 udebs => 9-10 udebs / subarch
> powerpc -- 5 subarchs -- 127 udebs => 25-26 udebs / subarch
counting apus, and around 39 udebs / subarch for 2.6 kernels
> s390 -- 1 subarch -- 7 udebs => 7 udebs / subarch
> sparc -- 2 subarchs -- 27 udebs => 13-14 udebs / subarch
you can see a trend there, with the hardware that has the most hardware
support (i386, ia64, powerpc, alpha), having the most .udeb modules per given
subarch, so there is not really a chance to disminish this magically without
rethinking the way module .udebs work.
> At least of the kernel images that currently build-depend on
> kernel-tree-2.4.27-* (alpha, hppa, i386, ia64, s390, sparc -- I assume these
> would be the first to be integrated if the patch were accepted), i386 is
> actually on the high end of both flavors and total udebs.
Well, forget 2.4 about this, this is most assuredly post-sarge stuff, and it
makes much more sense to think about 2.6 kernels in that way, and since there
is very little chance of huge patches going into 2.4 at this late stage of 2.4
development, the 2.4 patches are usually huge monolithic patches, and upstream
kernel development mostly concerns itself with 2.6 right now, it makes more
sense to think in term of 2.6/2.8 kernels here.
> Taking all archs together, the number of kernel udebs across all
> architectures and flavours seems to be 464. If there is a limit on how many
My count was at 303 for 2.6 kernels and 436 for 2.4 ones.
> binary packages per source the archive can handle, that probably does blow
> out the limit. I thought the limit was only on the number of binaries in a
> changes file, but I could be wrong.
>
> It would also be nice if the number of flavors required for d-i would go
> down over time, but that remains to be seen.
As far as powerpc is concerned, this can't happen unless we want to do some
huge amount of upstream kernel work to code for a common subset of the
powerpc/power instruction set, or decide to drop support for some hardware.
And we don't even have started to add the ppc64 kernels, which will come in 2
subarches, one of them having an extra flavour/optimization.
Friendly,
Sven Luther
Reply to: