Kernel Compiler missmatches

[Colin Watson]

On Fri, Feb 13, 2009 at 09:33:37AM -0500, Scott Kitterman wrote:
> 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).
> 
> 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).

My suggestion was #2, because this means that (a) future kernel builds
happen with the newer gcc and (b) users who don't use -updates get the
new gcc so that their local module compiles will work. Furthermore I
think it's probably not particularly good to have divergent versions of
gcc between -security and -updates anyway.

You seem to discard #2, but your objections don't match my understanding
of this option. Do we have different understandings? I'm saying that we
should copy gcc into -security; you're objecting to building -security
using -updates, which isn't what Andy's #2 says.

I do think, given the known state of the kernel, that we should update
gcc in -security shortly before a kernel ABI change in -security, to
minimise practical problems. Furthermore, in light of this problem we
should avoid changing the visible upstream version of gcc in future
post-release updates, even if it is necessary to backport some upstream
changes.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]