From: Paul Eggleton <paul.eggleton@linux.intel.com>
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:11:47 +0100 [thread overview]
Message-ID: <1448670.txDjULYI9R@helios> (raw)
In-Reply-To: <CAPhnLPA6GodRgpEKwyCdbVPOdv+s3nW3zp2rDUhuj3xw=K3L+g@mail.gmail.com>
On Friday 14 September 2012 13:50:22 Flanagan, Elizabeth wrote:
> 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.)
What do you mean by modutils? If you mean the earlier suggestion that module-
init-tools was missing from the manifest, I'm fairly certain that was a
misunderstanding because of it being replaced by kmod.
The thing is, we have no other means of accurately determining the contents of
the image than the installed package list, given that the package manager is
ultimately in charge of resolving and installing dependencies during image
creation. The list may not cover additional files copied into tmp/deploy as
part of building the image (kernel, bootloader, etc.) - however, that does not
make it inaccurate as to the contents of the image, let's be clear about that.
I agree we do need to write out the license information for these additional
files; however, since they aren't actually *in* the image itself, I think we
need to list these in a separate file. What happens for example if the system
builds u-boot as a result of building my image, but I don't ever end up
distributing that with the image?
As to the mechanism for picking these up, the only real possibility I can see
is to hook into do_deploy; this is not currently straightforward though since
that's not something that is implemented generically at the moment.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-09-14 22:24 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
2012-09-14 22:11 ` Paul Eggleton [this message]
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=1448670.txDjULYI9R@helios \
--to=paul.eggleton@linux.intel.com \
--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