Kernel Compiler missmatches

[Scott Kitterman]

On Fri, 13 Feb 2009 12:06:56 +0000 Andy Whitcroft <apw at canonical.com> wrote:
>We have a couple of reports indicating that following an update to Hardy
>their exernal modules no longer build.  Specifically those modules fail
>to build because the version of gcc used to build the kernel and the one
>installed and available to build the modules does not match.  The kernel
>highly recommends you use the same version, and most external modules
>sensibly enforce this.
>
>This missmatch has been triggered in Hardy because we recently did a
>security update to the kernel.  That was built in the -security environment
>which necesarily lacks any updates from -updates, and therefore has the
>released version of gcc.  This kernel was then pocket copied to -updates.
>At this point users of -updates have a kernel which was compiled with an
>older compiler than the one they have.  This is not desirable.
>
>There seem to be several simple options here:
>
>1) expect the users to build their own kernels if they want to use
>   external modules, or
>2) update gcc in -security, and always do so, or
>3) have separate kernel builds for each pocket (rather than pocket copying
>   the -security update into -updates, upload it there separatly with a
>   higher upload number).
>
>I guess the security team is best placed to evaluate the safety or
>otherwise of (2).
>
>Thoughts?
>

It has to be #1 or #3.  If -security were built with the -updates gcc, then 
you've just reversed the problem and broken things for people who don't use 
-updates.  This is a supported use case (the reason -security is built from 
-release).

I don't think #1 is a very Ubuntu approach and your #3 is the best solution.

Scott K