[OE-core] [RFC PATCH] license: Ensure we find multilib packages also

Richard Purdie richard.purdie at linuxfoundation.org
Fri Sep 14 22:09:57 UTC 2012


On Fri, 2012-09-14 at 13:50 -0700, Flanagan, Elizabeth wrote:
> On Fri, Sep 14, 2012 at 9:48 AM, Mark Hatle <mark.hatle at windriver.com> wrote:
> > On 9/14/12 11:01 AM, Richard Purdie wrote:
> >>
> >> On Thu, 2012-09-13 at 15:43 -0700, Saul Wold wrote:
> >>>
> >>> On 09/13/2012 03:31 PM, Paul Eggleton wrote:
> >>>>
> >>>> On Thursday 13 September 2012 12:26:19 Saul Wold wrote:
> >>>>>
> >>>>> Make sure to find -package, this was causing a failure
> >>>>> in the multi-lib build license generation during rootfs.
> >>>>>
> >>>>> Signed-off-by: Saul Wold <sgw at linux.intel.com>
> >>>>> ---
> >>>>>    meta/classes/license.bbclass |    2 +-
> >>>>>    1 files changed, 1 insertions(+), 1 deletions(-)
> >>>>>
> >>>>> diff --git a/meta/classes/license.bbclass
> >>>>> b/meta/classes/license.bbclass
> >>>>> index 29fe938..b29067c 100644
> >>>>> --- a/meta/classes/license.bbclass
> >>>>> +++ b/meta/classes/license.bbclass
> >>>>> @@ -88,7 +88,7 @@ license_create_manifest() {
> >>>>>         # list of installed packages is broken for deb
> >>>>>         for pkg in ${INSTALLED_PKGS}; do
> >>>>>                 # not the best way to do this but licenses are not arch
> >>>>> dependant iirc
> >>>>> -               filename=`ls
> >>>>> ${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head -1`
> >>>>> +               filename=`ls
> >>>>> ${TMPDIR}/pkgdata/*/runtime-reverse/*${pkg}| head -1`
> >>>>>                 pkged_pn="$(sed -n 's/^PN: //p' ${filename})"
> >>>>>
> >>>>>                 # exclude locale recipes
> >>>>
> >>>>
> >>>> Surely this could end up matching a the wrong file when one package name
> >>>> is a
> >>>> substring of another?
> >>>>
> >>> I am open to ideas here, I tried the ${MLPREFIX}, but it seems to be
> >>> empty when rootfs runs, that did not help, I thought about adding the
> >>> '-', but that would fail in the non-multilib case, how can I determine
> >>> what the prefix will be to get a more accurate match?
> 
> I'm not particularly happy with how we've been doing manifests for a
> while now and have been hacking at a revamp of it for the past 2
> months on and off.
> 
> We really shouldn't be relying on package data at all for license
> manifests. As the manifests are relying on list_installed_packages,
> they end up inaccurate anyway as list_installed_packages does exactly
> that. List software installed via package. Not installed via the
> package manager? Then you aren't in the manifest. This ends up missing
> quite a few things necessary from a release engineering standpoint
> (like, hey, modutils? The kernel? Not listed in the manifest. IMHO
> this is wrong.)
> 
> As a release engineer, I kind of don't really care if the software on
> my image was installed via the packaging system. I just want a list of
> what is on the images so I can audit my images to ensure GPL
> commitments.
> 
> One way I've been looking at fixing this is via event handlers. I'll
> have some code for RFC on this hopefully soon, but a preview (which
> may or may not work it's still a WIP) is at:
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=eflanagan/license_manifest
> 
> One thing the patch I've been working on does other than creates
> accurate manifests is it also tries to create a semi-compliant SPDX
> 1.0 manifest.
> 
> I know this is late in the cycle so it might not make 1.3, but this
> may be something we want to look at to end up solving this issue once
> and for all.

This depends whether this is a release manifest or an image manifest.
You likely want *both* under different circumstances. If the kernel is
installed in the image, it will be listed in the image manifest. We just
need to be really clear about what the manifest is for.

As for modutils, we use kmod now. Basically anything doing deployment
should have a manifest associated with it. That is do_deploy (kernel,
uboot, some small list of others) and do_rootfs. do_package_write_* are
also arguably deployment in another form, as are sstate feeds.

Cheers,

Richard





More information about the Openembedded-core mailing list