Re: kernel/d-i/security/release meeting at DebConf6
On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote:
> 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 ?
Immediately after I sent out the notes from this meeting, aba said
he'd followed up with an ftp master (neuro, iirc). From what he was
told, it sounds like the information we had during this meeting was
stale/inaccurate. Hopefully someone will update this thread with the
accurate information so that we can revisit this discussion. Many of
the attendees are still travelling (in fact, I'm replying to this
without a net connection, so it may be moot once it actually goes
out). It'll probably be a few days before everyone makes it home, but
then we can continue with a more well-informed discussion.
> > 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.
I think that the decision of whether or not to build them from
linux-2.6 is a separate issue. If doing so is the right thing, let's
do it, if its not, let's fix the build issue.
>
> > 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: ?) ?
Well, the only problem (aiui) is that kernel installs want to do bad
things like run bootloaders, etc. If we had a chroot parameter we
could tweak to turn this off, then wouldn't that solve this problem?
> > 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.
I sympathize with your concerns but, speaking as a person that does
security work and udeb maintenance for one architecture, I don't think
this is *that* big of a problem. ABI changes are more painful, but
d-i work can be ignored when releasing a security update (in fact, we
did so last time) - its just point release that suffer, and those
schedules are more flexible (as far as our users are concerned).
Where this would help solve time critical issues is *before* the
release of etch, where a late change could cause us to miss a release
deadline. However, the d-i team seemed to believe this was low-risk.
I do believe that our consensus was correct based on what we knew at
the time - however, it now sounds like this information may have been
incorrect so we should re-discuss.
--
dann frazier
Reply to: