On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: > Kernel udeb creation process (possibly using k-p?) > ------------------------------------------------- > If we build all of the *existing* udebs from a single source, we outgrow > the limit of the Binary: field in the control file.
Huh ? This problem is known since over 2 years now, and i thought it was one of the things that where fixed earlier this year or late last year ? > A second limitation exists in sarge's version of apt, which is what we might > be running on ftp-master. Not an issue if we start this with etch + 1 > this will create an upgrade problem for users. Why is this an issue ? The longer Binary: field will only be used in the source package file, right, and as such, it should be no major problem if sarge's apt has a problem with it. The pure binary package file should be mostly ok, so sarge's apt should be happy with this issue. What am i missing here ? > buildd issue - it'd be nice if we could be from an unpacked kernel, but you > can't build-dep on that so its a FTBFS. Which is why it makes the most sense to build them from linux-2.6, but i won't argue this point here. > udebs/deb creation is currently separate - is that a feature? > svenl has noted that a porter has to select modules twice - during the > kernel build and during the udeb creation > > manoj wonders if maybe kernel-package can do this work. he wouldn't > want to build the per-arch mapping into k-p, but might take these from > lists on the file system > > joeyh notes that kernel-wedge could also support this additional functionality > > Frans points out that his preference is to continue to keep udeb > generation separate from the mainline kernel, to avoid having to do a > full kernel release each time we shuffle udeb contents. Yep. Altough these days we upload .deb kernels more often than the d-i team uploads .udeb packages of the same :) > Frans believes that sepearate source packages are more feasible for allowing > this type of shuffling Indeed. but there is the FTBFS issue mentioned above and which needs solving. > dannf suggested that maybe k-p can be configured to allow simple unapcking of > debs vs. all the postinst configuratin to allow autobuilders to deal with > udebs > better; manoj thinks that this will be possible but further out in the current > k-p transition that allows for users to do more "overriding" of > postinstallations by default. Mmm. But i don't see how this will play nice with the auto-builders. There is no way we can get this behaviour into the current set of deps/build-deps. Should we add another new kind (Source-dep: ?) ? > manoj> new kernel package will have some new features the kernel team might > like > - versioning is messed up, manoj is integrating abi number, etc, into k-p > > dannf> what if we split up centralized udeb source packages to manage a > certain > set of archs > > The consensus was that the current udeb approach is suboptimal, but > solving it cleanly won't be possible until etch+1. None of the > attendees considered this issue to be critical for etch, so the > current plan is to status quo and wait till etch so that we can come > up with a good solution. I strongly disagree with this. The non-solution of this issue means that we have a limited power to handle abi-breaking security and bug-fix patches, and impose unreasonable earliness on the kernel freeze for etch, as well as endangers security support during etch's lifetime after that. This was and is a problem with sarge, and we should not repeat that. We should have tackled this issue last fall though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
