Re: 2.6.12 is in testing
On Wed, Sep 14, 2005 at 10:53:30AM -0400, Joey Hess wrote:
> Sven Luther wrote:
> > Is this not the moment to modify the way our kernel .udeb packages are built,
>
> It's not a prerequisite for getting a working release of d-i for etch. I
> think our users are more interested in being able to install using the
> new kernel.
Yeah, well, if the maintainability of the code improves, ...
> > 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.
>
> I assume you mean the kernel-image udebs and not all the modules that
> lack any prefix. I really doubt some other OS will conflict with eg,
> kernel-image-2.4.27-2-386-di, and IIRC some parts of d-i have the
> "kernel-image" part of the name hardcoded in them, but a comprehensive
> patch would not be ignored.
Ok, was just for tydying up anyway.
> > 1) keep the sarge code as is, and use it only when installing sarge.
>
> Great, send a patch..
Well, was planing to work on that in oldenbourg, does that sound great ?
> > 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.
>
> If the kernel team would really like to handle issues like detecting
> whether an i386 machine running a UP kernel is SMP, I'd be very happy
> for the code for that to move there. However, I don't think the 1:1
> subarch mapping you describe actually exists; it's rife with special
> cases. Colin already designed the code to factor out common information.
Yep, upto a point, but imagine that code could also be reused for normal
upgrades or something.
> > 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.
>
> At times in addition to the ramdisk space, up to three programs
> (main-menu, anna, udpkg) can be running concurrently that all have to
> hold udeb state in memory. Care to calculate how much memory that would
> waste? (Make sure to take into account the memory that would have to be
> used to represent all the inter-module dependencies.)
Mmm, why is this tripple need of holding udeb state necessary ? Would not
solving this go a great way for diminishing general memory usage anyway ?
> > 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.
>
> Alternatively, kernel team members who maintain an architecture could
> already take resposibility for rebuilding (and testing, which your
> proposal does not take into account, and without which any given kernel
> upload would be statistically likely to break d-i on some arch) the
> udebs as part of the release process for a new kernel. There's no reason
Nope, with the common kernel package we did take great care to *NOT* need
individual maintainers to do the upload, and to not need each porter to make
uploads, and thus we heavily dislike you putting the burden on us like that
again (well, i dislike, but i think the rest of the kernel team will echo
this). And no, why would d-i break more than the kernels would ? And i believe
you should maybe rething the etch/sid separation to handle this, with sid d-i
builds being sometimes broken, but etch being ok. That's what we have unstable
for :)
> for the udeb builds to lag the kernel builds by more than a day or two,
> and they don't for architectures that have an active maintainer already
> doing this (for 2.6, this is already happening pretty well for i386,
> sparc, powerpc, and ia64).
Exactly that is the problem, they lag because there is a human factor involved
for something which is pretty automated. that said you told me in HEL that you
could easily enough setup a automated or semi-automated rebuild and upload
infrastucture, so ...
I still think my proposal makes more sense in the long run, but let's discuss
this more in oldenbourg.
Friendly,
Sven Luther
Reply to: