[oe] [RFC] Rebuild external kernel modules on kernel change

[Richard Purdie]

On Sat, 2009-04-04 at 15:31 +0200, Koen Kooi wrote:
> For beagleboard I have a few things I need to rebuild everytime the 
> kernel changes:
> 
> * powervr kerneldrivers
> * sdma kernel module
> * dmai kernel module
> * codec-engine
> 
> And I have roughly two kinds of kernel changes:
> 
> 1) version upgrade (e.g. 2.6.29 -> 2.6.29)
> 2) config changes (e.g. enable ethernet bridging)
> 
> The first type of change could be solved by putting KERNEL_VERSION in PV 
> or PR, but that needs a non-trivial amount of python since the 
> information isn't available at parsing time (exactly like debian.bbclass).
> The second kind of change is a lot harder to detect, unless we start 
> storing md5sums for kernel defconfigs.
> 
> I have a lowtech proposal for this:

The thing is if we start doing this for kernels, we'll probably end up
having to do it for other things and the end result will be a mess.

A better fix for this is BB_STAMP_POLICY = "whitelist" which will at
least cause the right things to rebuild.

No, this doesn't bump the PR when packages change but I'd actually like
to see some new code to fix this problem and several others once and for
all. The idea would be to "compare" the current build with any previous
ones and error if bad differences are detected. In this case if PR = X
had already built that would be an "error" which the system may work
around by using PR = "X-Z1" in the output packages. You could teach that
code interesting (even distribution specific) logic e.g. to ignore
changes in system libraries like libc.

This would imply this comparison data would have to come from a shared
source for multiple build machines for a distribution like Angstrom.

No, this solution isn't simple but hacking around the problem just
builds a house on top of quicksand ;-).

Cheers,

Richard