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

Paul Eggleton paul.eggleton at linux.intel.com
Fri Sep 14 22:11:47 UTC 2012


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




More information about the Openembedded-core mailing list