On 9/14/12 5:26 PM, Flanagan, Elizabeth wrote:
On Fri, Sep 14, 2012 at 3:11 PM, Paul Eggleton
<paul.eggle...@linux.intel.com> wrote:
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.
Correct. Even so, there are things obviously missing from the
manifests. Kernel is the most obvious.
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.
No, but it's like the joke about the two software managers in a hot
air balloon asking the engineer on the group where they are only to be
told "In a hot air balloon". It's technically correct but the user
case I keep running into here is that people want to know what they're
deploying with a product. The expectation people have (and right or
wrong, it's what I keep running into) is that everything that's on the
hddimg is what is on the manifest.
From thinking about the deployment of the rootfs through images, it seems to me
it should be the responsibility of the components populating the items to
produce a manifest of what they've done. Be it install a package, or copy a
file. Then at the end collect together these manifest fragments to describe
exactly what was done (and where it was done to!).
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?
Then you have a manifest that has software that you end up complying
with the GPL (when you don't really need to) verses having a manifest
that doesn't list software which you do need to comply with the GPL.
Both are wrong, but one is more wrong.
RP is right here. We probably need to list a few different use cases
here and support the most common ones.
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.
I'm currently hooking into do_package because, as best I can figure it
out, everything ends up getting packaged, even if it's not installed
via package. I'm happy for other suggestions though.
-b
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
