On Tue, May 23, 2006 at 07:08:41PM +0200, Sven Luther wrote: > On Tue, May 23, 2006 at 09:47:08AM -0700, Steve Langasek wrote: > > On Mon, May 22, 2006 at 11:38:46PM +0200, Sven Luther wrote: > > > On Mon, May 22, 2006 at 01:52:47PM -0700, Steve Langasek wrote: > > > > > Perhaps we disable new kernel features for etch 1/2? e.g., limit new > > > > > feature to new hardware support. For example, we wouldn't want to > > > > > turn on something as drastic as preempt in a stable update. > > > > So how do you structure this? I would expect that updates limited to new > > > > hardware support shouldn't normally change the kernel ABI at all, which > > > > makes it hard to make both the old and new kernel versions available for > > > > installation. > > > > If it is a new kernel ABI (either because the version number has simply been > > > > changed on it, or for other reasons), what gets done with out-of-tree module > > > > packages? > > > If ever the new out-of-tree module and d-i kernel reunification is in place, > > > it will be easy enough to rebuild all packages which depend on the abi-changed > > > kernel. > > "rebuilding" them doesn't address the question of making them available for > > both old and new kernels. Since the assumption seems to be that etch 1/2 > Well, they will obviously have the abi number embedded in their package name, > and a virtual package / provides who will handle the transition, so this > should be no real problem. It is a technology that is well proven and mastered > since years in debian. See the ocaml example. Er, the problem is that you're talking about keeping *two* sets of packages around. That implies two source packages; at least some members of the ftp team don't like having source packages building binaries that aren't mentioned in debian/control of the source package, and keeping one source package for two kernel versions, one of them added at a later date and for an undetermined version, pretty definitely means that one set of these binaries aren't mentioned in debian/control of the current source package. The ftp team might be ok with making an exception here, I'm just saying that's a conversation to have *before* release instead of when it comes time to do etch 1/2 and people suddenly realize there's no infrastructure to fully support both kernels. > > uses a different upstream kernel version than etch, to be able to continue > > providing security support for the etch versions it seems that you need a > > separate source package (or a whole new suite in dak complete with w-b > > support!) for any packages being rebuilt against the etch 1/2 kernel. > You need a source package, which will be able to generate its debian/control > semi-automatically, to adjust to the kernel abi change, yes. This is also > something we have done in the ocaml case recently. Needs some coordination and > policy for the out of tree modules, and maybe binNMUs who are able to > regenerate the debian/control in this way, but nothing otherwordly. Changing the list of packages in debian/control in the standard debian/rules targets is almost always something we treat as an RC bug; so binNMUs are definitely out. Which means sourceful uploads, which means the binaries for the old kernel no longer correspond to the current source package, which means rene tags them as candidates for removal... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature