Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Flanagan, Elizabeth" <elizabeth.flanagan@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [RFC PATCH] license: Ensure we find multilib packages also
Date: Fri, 14 Sep 2012 23:09:57 +0100	[thread overview]
Message-ID: <1347660597.13596.24.camel@ted> (raw)
In-Reply-To: <CAPhnLPA6GodRgpEKwyCdbVPOdv+s3nW3zp2rDUhuj3xw=K3L+g@mail.gmail.com>

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@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@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




  reply	other threads:[~2012-09-14 22:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-13 19:26 [RFC PATCH] license: Ensure we find multilib packages also Saul Wold
2012-09-13 22:31 ` Paul Eggleton
2012-09-13 22:43   ` Saul Wold
2012-09-14 16:01     ` Richard Purdie
2012-09-14 16:48       ` Mark Hatle
2012-09-14 20:50         ` Flanagan, Elizabeth
2012-09-14 22:09           ` Richard Purdie [this message]
2012-09-14 22:11           ` Paul Eggleton
2012-09-14 22:26             ` Flanagan, Elizabeth
2012-09-14 22:31               ` Mark Hatle
2012-09-14 23:09               ` Paul Eggleton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1347660597.13596.24.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=elizabeth.flanagan@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox