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