[OE-core] [PATCH 1/1] license.bbclass: Splitting out licenses

Flanagan, Elizabeth elizabeth.flanagan at intel.com
Wed Jul 27 18:04:32 UTC 2011


On Tue, Jul 26, 2011 at 4:00 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Tue, 2011-07-26 at 08:15 -0700, Flanagan, Elizabeth wrote:
>> On Tue, Jul 26, 2011 at 7:57 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>> > On Mon, 2011-07-25 at 16:24 -0700, Flanagan, Elizabeth wrote:
>> >> Adding a bit more functionality here:
>> >> 1. Adding some more SPDX Maps to take care of + licenses
>> >> 2. Strip out -native and -cross package license wrangling.
>> >>    If it doesn't go on the image, we shouldn't wrangle it.
>> >> 3. Split out the license destination directory to a
>> >>    IMAGE_NAME time stamped dir in
>> >>    /tmp/deploy/licenses/${IMAGE_NAME}/<stamp>
>> >>
>> >> I've removed the handler from my previous Pull as license
>> >> manifest needs more discussion and I don't want these
>> >> bug fixes to be held up by an added feature.
>> >
>> > I obviously don't understand this code :/
>> >
>> > What happens when I run "bitbake core-image-minimal core-image-sato",
>> > i.e. when I build two images in one build?
>> >
>> > I suspect this current approach is flawed and we actually need to
>> > postprocess the installed package list after do_rootfs completes at
>> > image generation time to build the *real* list based on the installed
>> > packages?
>> >
>>
>> Yes. I've found that this approach is definitely flawed. It works
>> great for a single image build. Outside of that it acts funny, like
>> you mentioned and can return incorrect results. I'm planning on
>> revisting this soon.
>>
>> I'm suspecting that your suggested approach is the way it'll have to
>> be. Looking at what is generated by various runs and I see issues.
>>
>> > This code is obviously still needed as it would provide the basis so the
>> > code can get the licenses it needs to pull together...
>>
>> Yes, agreed.
>
> So with this in mind, where does that put this pull request? :)

I would still pull it. It does give us a basis to work on and splits
things out a bit.
When I get back from the conference this week, I'll fix it so that
it's a more reliable
in returning results. My guess is that I'll have to rip this all out
from being event driven
and do it, as you suggest, a postprocess right after do_rootfs

-b




More information about the Openembedded-core mailing list