Re: [PATCH 1/5] base.bbclass: add support for LICENSE_FLAGS

[Saul Wold <sgw@linux.intel.com>]

On 01/06/2012 06:34 PM, tom.zanussi@intel.com wrote:
> From: Tom Zanussi<tom.zanussi@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@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('+', "\+")