On Tue, May 23, 2006 at 10:16:37PM -0500, dann frazier wrote: > 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.
Notice that this issue was mentioned in a thread on debian-boot at least some weeks ago, i am not sure, but it may even have been Joeyh who mentioned it. I also mentioned it earlier, altough i was not 100% sure. > > > 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? Ah, that would indeed be a solution, we could easily implement something such, together with Manoj, since i believe it involves kernel-package, and how the /etc/kernel/*.d/ scripts are run. Not sure if this is enough, as we would also obviously need support from the buildd software. > > > 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). Well, as a proof of my claims, the sarge d-i released with a known remote security hole, and there has been no (or maybe 1 by now ?) d-i update since then. > 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. Yeah, well, i disagree on this. Taking the last time as example, all development on the kernel was frozen by the d-i team, and we released with a known remote exploit in d-i. And again this time, d-i freeze is scheduled first week of august, and this means we need to have the kernels frozen a week or so before that. This is something like 5 month before the actual release date of etch. So, given these, i am dubious of any claim on the subject made by the d-i team. > 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. I have some trouble with this too, i believe that at least some in the meeting must have known about this new information, and either forgot about it, or chose to ignore it, or whatever. Friendly, Sven Luther > > -- > dann frazier > > --------------------------------------------------------------------------------------- > Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
