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 <mikehab...@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 <pi...@toganlabs.com> wrote: >> >> On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi <mikehab...@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 >> > -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
