[OE-core] RFC: Maintain backwards compatibility or not for module-base.bbclass

[Peter Kjellerstedt]

Background: Back in September, Richard made a commit to 
linux-libc-headers.inc describing why one should not fork the 
linux-libc-headers recipe:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=babbf7a46acaefd9b36031483cafce053f607e66

As a result I created a local bbclass for our layer called 
kernel-headers, which provides a recipe with kernel headers 
that match the actually used version of the Linux kernel.
This was needed for packages that need to access hardware 
specific features that are not present in the generic kernel 
headers provided by linux-libc-headers.

My intention for this class was that it should be generic 
enough to be able to upstream it to OE Core.

Now, the other day a colleague of mine had a build failure due 
to this class. It turned out that even though the class adds a 
dependency on virtual/kernel and then uses the files that are 
installed to ${STAGING_KERNEL_DIR} when running oe_runmake 
headers_install, the command could fail because the 
${STAGING_KERNEL_DIR}/scripts was not populated. After asking 
Richard about this, I learned that this is due to problems 
with the sstate cache and not knowing whether a 32 bit host or 
a 64 bit host was used to generate the files. Thus I also 
learned that the scripts are actually built as a result of 
building modules.

Since I did not want my class to depend on modules having been 
built, I looked into modules.bbclass and modules-base.bbclass. 
There I found the function do_make_scripts() which is 
responsible for building  the kernel scripts. However, the 
current setup doesn't lend itself very well to use the 
modules-base.bbclass for something other than modules.

My idea then was to break this part out into a separate class, 
kernel-scripts, which I did. You can find both the 
kernel-scripts and kernel-headers classes here: 

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers

When I showed this to Richard he noted that my change was not 
backwards compatible (as I no longer provide the 
do_make_scripts() function from the module-base.bbclass). 
However, there is nothing besides module.bbclass in OE Core 
and meta-oe that use the module-base.bbclass.

Anyway, I made a modified version that does maintain backwards 
compatibility for module-base.bbclass here:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers-backwards-compatible

This time Richard complained about the extra class 
(kernel-scripts-base.bbclass), and noted that there was no 
way to win... He then suggested that I take the question of 
whether we need to maintain backwards compatibility for 
modules-base.bbclass to the mailing list.

So, here I am now. I do not know who else use the 
do_make_scripts() function from module-base.bbclass and in what 
way, and whether restructuring the functionality into the new 
kernel-scripts.bbclass without maintaining backwards 
compatibility would be a problem. If you know anything about 
this, please let me know.

Any comments appreciated.

//Peter