Kernel 2.6.16 for Dapper LTS?

Anders Karlsson trudheim at gmail.com
Tue May 9 22:54:06 BST 2006


On Tue, 2006-05-09 at 10:56 -0700, Matt Zimmerman wrote:
> On Tue, May 09, 2006 at 05:25:36AM +0100, Anders Karlsson wrote:
> > On Mon, 2006-05-08 at 14:25 -0700, Matt Zimmerman wrote:
> > > That's a bit unfortunate, because 2.6.16 was not ready at the time when we
> > > needed to make this decision.  We've put a lot of work into stabilizing
> > > 2.6.15, though (including backporting bugfixes), and it's looking very good.
> > 
> > Question,
> > 
> > If 2.6.16 becomes a better choice for Dapper, maybe in July, November or
> > early next year, would a proper Ubuntu sanctioned kernel package be made
> > available in dapper-extras or dapper-backports ?
> 
> Whether it could go into dapper-backports would depend heavily on how
> exactly the package was derived.  The usual approach for -backports is to
> build the package from the development release, which in the case of Edgy
> could be somewhat aggressive.

So the -extras repository would, if it ever happened, be a better place
for it if the kernel package and connected required packages were to be
made available.

> Also, as Scott pointed out, corresponding updates to the udev subsystem (and
> possibly other related packages) would need to track the new kernel.

I realise the implications for certification etc., that changing the
kernel version would invalidate any certifications the release has
acquired.
My thought were that there may be legitimate reasons, not security
related, for why 2.6.16 or 2.6.17 (when it arrives) would be preferred
over the shipped kernel. People may want the stable release, but use a
recent nvidia or ati driver for a brand new gfx card in 12-18 months
time when those drivers rely on an abi in the kernel that isn't in
2.6.15. 

> In principle, I'm not opposed to kernel backports, but understand that the
> issues are complex and someone dedicated and knowledgeable would need to
> tend to them.

So if there were some{one, people} that looked after it, did QA etc., it
would be feasible - if I read you right. Maybe such a venture should
have its own separate repository so there would be no accidental
inclusion of such packages. Just thinking out loud...

Thanks for the replies.

-- 
Anders Karlsson <trudheim at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3838 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20060509/560219bd/smime.bin


More information about the ubuntu-devel mailing list