Re: 2.6.12 is in testing
On Tue, Sep 13, 2005 at 10:50:58PM -0400, Joey Hess wrote:
> Well, 2.6.12 has finally made it into testing. I must confess I thought
> this would happen over one month before now, but now that it is, we have
> no excuse to not get a d-i beta out soon.
>
> There's still some work to do to switch d-i away from 2.6.8. We need to
> make sure that the new base-installer successfully installs 2.6.12
> kernels with the new linux-image names. Some work for this has been done
> for powerpc, i386, ia64 and sparc, but not for other architectures that
> can use 2.6, like hppa and amd64. And we still need to test it and make
> sure it works of all these architectures.
>
> Some architectures haven't been updated to use 2.6.12 udebs yet, and we
> really can't keep the kernel team waiting of that much longer. This
> includes hppa, m68k (not used yet), alpha (2.6 udebs not in archive). A
> few other architectures may need udeb updates to be current with the
> latest 2.6.12 kernels.
Joeyh,
Is this not the moment to modify the way our kernel .udeb packages are built,
and either use a single package building all .udebs or at least some common
infrastructure for building them all if there is still problems in the
archive, i feel that anything else would be unreasonable now that all arches
are built from the same source packages (except mips/mipsel, but they will be
folded in soon, i hope).
Also, i propose that we rename the kernel .udebs to use the linux- prefix, as
the .debs have done, to pave the way of futur non-linux support (hurd, *bsd or
others like opensolaris maybe). This sounds a good time to do so.
The next point would be for base-installer/kernel. I have thought about it
some, but me talking about that on irc faced only a huge wall of silence, so i
make the proposal here again.
The gist of it is that :
1) modifying b-i/kernel will break sarge installs with the etch/sid d-i's.
2) the kernel .debs are now built from a common package, and it doesn't
really make sense to have 12+ different code snipplet, all being subtly the
same but with individual differences in b-i/kernel.
So, the secon proposal is to :
1) keep the sarge code as is, and use it only when installing sarge.
2) propose a new unified b-i/kernel code aiming at etch/sid kernels, and
using the linux-image-<flavour> thingy.
This new code could probably just use some per-arch rules to detect flavours,
and it would even be possible in the long run to migrate that code to the main
linux kernel packages, in order keep it at one place only, also porters know
best what flavours match what subarches and so on, but we will see.
The last point is that i would much prefer a 1 module per .udeb solution over
the existing mess (where modules are assigned to .udebs in a rather arbitrary
fashion, which often break on non-mainstream arches/subarches). I hear this
has too much of a packaging overhead (but is this really the case ? Anyone
claiming this can argument this case with real info ?), so another solution
for the kernels could be found, where modules are not-packaged ?
Anyway, i had a look at the "packaging overhead". Each module .udeb contains a
(rather short) control file (498 bytes for the hfs powerpc modules), a file
hierarchy, and the modules. The overhead over just the modules. The overhead
seems to be 4k per directory node, and a half k for the control file. So is
this really an overhead we are worried about.
The only real problem would be the number of packages issue, but if we go this
way, we could build the .udebs automatically from the kernel packages, and
then have the whole kernel build problem take only a couple of days for all
autobuilders to build the packages, and there would be no delay due to the
kernel for d-i.
Friendly,
Sven Luther
Reply to: