[OE-core] [PATCH 1/5] base.bbclass: add support for LICENSE_FLAGS
Saul Wold
sgw at linux.intel.com
Sat Jan 7 05:10:34 UTC 2012
On 01/06/2012 06:34 PM, tom.zanussi at intel.com wrote:
> From: Tom Zanussi<tom.zanussi at intel.com>
>
> LICENSE_FLAGS are a per-recipe replacement for the COMMERCIAL_LICENSE
> mechanism.
>
> In the COMMERCIAL_LICENSE mechanism, any package name mentioned in the
> global COMMERCIAL_LICENSE list is 'blacklisted' from being included in
> an image. To allow the blacklisted package into the image, the
> corresponding packages need to be removed from the COMMERCIAL_LICENSE
> list. This mechanism relies on a global list defined in
> default-distrovars.inc.
>
> The LICENSE_FLAGS mechanism essentially implements the same thing but
> turns the global blacklist into a per-recipe whitelist. Any recipe
> can optionally define one or more 'license flags'; if defined, each of
> the license flags defined for a recipe must have matching entries in a
> global LICENSE_FLAGS_WHITELIST variable. Typically a recipe will have
> a single license flag specific to itself, which allows it to be
> individually toggled on and off. For example, a package named 'foo'
> might define a single license flag, 'commercial_foo':
>
> LICENSE_FLAGS = "commercial_foo"
>
> This says that in order for the foo package to be included in the
> image, the string 'commercial_foo' must appear in the
> LICENSE_FLAGS_WHITELIST variable:
>
> LICENSE_FLAGS_WHITELIST = "commercial_foo"
>
> Because the typical case is indeed to create LICENSE_FLAGS containing
> the package name, the LICENSE_FLAGS could just as well have been
> specified as:
>
> LICENSE_FLAGS = "commercial_${PN}
>
> which would pick up the package name automatically.
>
> The mechanism has the word 'flags' in the name because although the
> typical case is to specify a single string to match as above, the user
> can add additional strings that might be thought of additional
> 'attributes' of a license that also need to be matched. This allows
> for the creation and specification of license categories that could be
> used to flexibly match sets of packages that match certain attributes
> without forcing them to all be specified individually. For example, a
> particular set of recipes that are typically used together might all
> contain a 'commercial_video' flag. Additionally, some of them might
> specify an additional 'binary' flag meaning that it's not possible to
> get the source for those packages. Specifying both 'commercial_video
> and binary' in the LICENSE_FLAGS_WHITELIST would allow them all to be
> pulled in, but if 'binary' was missing, it would only allow those
> packages that had source to be allowed in to the image.
>
> The current behavior of COMMERCIAL_LICENSE is replicated as mentioned
> above by having the current set of COMMERCIAL_LICENSE flags implement
> their using LICENSE_FLAGS = "commercial_${PN}.
>
> That being the case, the current COMMERCIAL_LICENSE can equivalently
> be specified in the new scheme by putting the below in local.conf:
>
> # This is a list of packages that require a commercial license to ship
> # product. If shipped as part of an image these packages may have
> # implications so they are disabled by default. To enable them,
> # un-comment the below as appropriate.
> #LICENSE_FLAGS_WHITELIST = "commercial_gst-fluendo-mp3 \
> # commercial_gst-openmax \
> # commercial_gst-plugins-ugly \
> # commercial_lame \
> # commercial_libmad \
> # commercial_libomxil \
> # commercial_mpeg2dec \
> # commercial_qmmp"
>
Would it not make sense to add this to local.conf.sample.extended in
meta-yocto?
This won't hold up this patch set.
Sau!
> The above allows all of the current COMMERCIAL_LICENSE packages in -
> to disallow a particular package from appearing in the image, simply
> remove it from the whitelist.
>
> Signed-off-by: Tom Zanussi<tom.zanussi at intel.com>
> ---
> meta/classes/base.bbclass | 19 +++++++++++++++++++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index e65a722..4aeba1b 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -349,6 +349,25 @@ python () {
> if license == "INVALID":
> bb.fatal('This recipe does not have the LICENSE field set (%s)' % pn)
>
> + def skip_package(pn, flag):
> + bb.debug(1, "Skipping %s because it has a restricted license (%s) not"
> + " whitelisted in LICENSE_FLAGS_WHITELIST" % (pn, flag))
> + raise bb.parse.SkipPackage("because it may require a special license"
> + " to ship in a product (listed in LICENSE_FLAGS)")
> +
> + def all_license_flags_match(flags, whitelist):
> + for flag in flags.split():
> + if not flag in whitelist.split():
> + return False
> + return True
> +
> + license_flags = d.getVar('LICENSE_FLAGS', True)
> + if license_flags:
> + license_flags_whitelist = d.getVar('LICENSE_FLAGS_WHITELIST', True)
> + if not license_flags_whitelist or not all_license_flags_match(
> + license_flags, license_flags_whitelist):
> + skip_package(pn, license_flags)
> +
> commercial_license = " %s " % d.getVar('COMMERCIAL_LICENSE', 1)
> import re
> pnr = "[ \t]%s[ \t]" % pn.replace('+', "\+")
More information about the Openembedded-core
mailing list