Re: kernel/d-i/security/release meeting at DebConf6
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
Reply to: