On Mon, 2012-01-09 at 16:01 -0800, Saul Wold wrote: > On 01/06/2012 09:13 PM, Tom Zanussi wrote: > > On Fri, 2012-01-06 at 21:10 -0800, Saul Wold wrote: > >> On 01/06/2012 06:34 PM, [email protected] wrote: > >>> From: Tom Zanussi<[email protected]> > >>> > >>> 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<[email protected]> > >>> --- > >>> 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('+', "\+") > >> > With all the discussion about License related stuff on the list and IRC, > I think we should be creating a bbclass to define and hold these flags. > Then there is just a call from base.bbclass into check_license_flags > and return True/False for the skip_package(). >
So move this code into a separate .bbclass, ok. > And based on a comment from Chris L. on the IRC, will this handle > package level LICENSE_FLAGS, this is recipe level currently, correct? > Right. > It could be you have some recipe with multiple binaries (for example) > some are OK and some are not and they are packaged separately. Can the > LICENSE_FLAGS handle this? > No, I don't think so, there's just the per-recipe LICENSE_FLAGS. How would that be expanded to per-package? Tom > Sau! > > >> _______________________________________________ > >> Openembedded-core mailing list > >> [email protected] > >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > > > > > _______________________________________________ > > Openembedded-core mailing list > > [email protected] > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
