Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
> 
> Exactly. And I had windriver bug with the same symptoms as yours. It
> was a package
> that built its own modules, and hence never called this either.
> 
> > and my recipes did override module_do_compile task but not do_compile like below
> >
> > module_do_compile() {
> >         oe_runmake
> > }
> >
> > so, is comment wrong there should it say module_do_compile instead ?
> >
> > will it work with sstate always ?
> >
> > it will be OK to revert it if thats the case.
> 
> I'll come up with something that works in all cases. The sstate fix is
> better from the point
> of view that it is transparent to the recipes, and they don't need to
> do anything special
> for the support.
> 
> So my proposal is this:
> 
>  - fix the new bug at hand by making the sstate change depend on the
> toolchain (I agree
>    that patching the scripts to not reference the target toolchain
> isn't a good idea since not
>   all kernels get the rix).

Can we please not do this? Adding in toolchain dependencies into the
sstate code whilst possible, is going to massively complicate the
dependency chains and is a last possible resort. I bought that argument
in the useradd case since there are horrible issues there. We don't have
that issue here.

In kernel terms, its safer/easier to hack the kernel makefiles than
expecting sstate to work well with dependencies like that embedded in
it.

>  - remove the modules-base.bbclass scripts recreation, so we only have
> one scripts
>    restore in the tree.
> 
> Alternatively, recipes need to be fixed to call the
> modules-base.bbclass routine to restore
> scripts, and I think it is obvious that won't work in all cases.

Which cases won't that work in?

As far as I'm concerned, people using module-base are taking a loaded
gun and are expected to use it safely (which means calling
do_make_scripts somehow). People wanting a safer ride can use module
which adds the appropriate task for them.

The comments in the bbclass files do need fixing but that is trivial to
sort out.

> I'll wait for comments/concensus before sending a new patch (which
> needs to be tested
> on all the cases), but in the meantime, the patches to the list to fix
> the sstate solution are good to be applied.

I will respectfully disagree ;-).

Cheers,

Richard