[OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

Bruce Ashfield bruce.ashfield at gmail.com
Mon Sep 24 13:48:26 UTC 2018


On Mon, Sep 24, 2018 at 9:46 AM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Mon, Sep 24, 2018 at 9:44 AM,  <richard.purdie at linuxfoundation.org> wrote:
>> On Mon, 2018-09-24 at 13:42 +0000, Mikko.Rapeli at bmw.de wrote:
>>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie at linuxfoundat
>>> ion.org wrote:
>>> > I was replying from the perspective of how this should work in
>>> > general.
>>> > I agree that for this to work with a kernel recipe we do need the
>>> > change that started this thread and that is probably a reasonable
>>> > thing
>>> > to do.
>>>
>>> Good, then my patch is not going in the wrong direction.
>>>
>>> Remaining problem is if file overwrites will be detected or not so
>>> that
>>> accidental overrides of files in linux-libc-headers from kernel
>>> recipes
>>> should not be possible...
>>
>> That is a general problem and the core sstate code shouldn't let that
>> happen these days so I think that is already covered?
>
> Yep, it should be covered. I was just looking for confirmation.
>
> Can everyone have a look at:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305
>
> And confirm that it can be closed by this .. ? I suggested my approach
> in that bug, but it
> never went anywhere at the time.

Sorry for all the email, I hit send a bit too soon.

The only issue that would remain for that bug is that there's no
standard/default location for those exported extra headers, and it
is up to the kernel recipe packager to make sure that their recipes
know where to look for them.

I'm not convinced there has to be a standard location for them, so
I'll all for closing that old bug.

Bruce

>
> Bruce
>
>>
>> Cheers,
>>
>> Richard
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the Openembedded-core mailing list