[OE-core] [PATCH 1/5] base.bbclass: add support for LICENSE_FLAGS
Tom Zanussi
tom.zanussi at intel.com
Sat Jan 7 05:13:07 UTC 2012
On Fri, 2012-01-06 at 21:10 -0800, Saul Wold wrote:
> 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?
>
Yes, I was going to do that, but didn't want to bother if it wasn't
going anywhere. I'll send a patch for it...
Tom
> 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('+', "\+")
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
More information about the Openembedded-core
mailing list