Re: Generating license/manifest for a specific layer?

[Beth Flanagan <pidge@toganlabs.com>]

Ok, I guess my question there then would be is how you'd determine
where a recipe "lived". Like, if meta-foo has a bbappends for
something in core, would you include it or not in your manifest?

If so, then taking the original manifest and just doing some text
manipulation in a ROOTFS_POSTPROCESS_COMMAND would be the way I'd
probably look at tackling it.

On Wed, Jun 13, 2018 at 2:42 PM, Michael Habibi <mikehabibi@gmail.com> wrote:
> Beth,
>
> This is for internal consumption. We want to be able to generate a full
> manifest, and also one that reflects how we diverged from base Yocto
> distribution.
>
> On Mon, Jun 11, 2018 at 10:55 AM Beth Flanagan <pidge@toganlabs.com> wrote:
>>
>> On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi <mikehabibi@gmail.com>
>> wrote:
>> > Our use case is to capture the license files, manifest
>> > (package/version),
>> > and download information only for packages we modify/add. We use our own
>> > layer to modify/add packages, everything coming from standard Yocto
>> > layers
>> > are untouched.
>> >
>> > Is there a way to generate this information on a layer-by-layer basis,
>> > instead of a full manifest that includes all standard, unmodified
>> > packages?
>>
>> The easy (cheating) way, would be to modify the tmp/deploy/licenses
>> artifact post build (I do it to remove -native- and -cross- from
>> things I distribute as I'm not actually distributing them) or put in a
>> post do_rootfs function that does it.
>>
>> I guess my question would be (and this is less a technical question
>> and more of a legal one) is why would you want to only include a
>> manifest for only part of what you're distributing (or am I
>> misunderstanding what you're trying to do here?)
>>
>> -b
>> >
>> > --
>> > _______________________________________________
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>> >