Skip to contentSkip to conversation

default-distrovars.inc: drop obsolete LGPLv2_WHITELIST_GPL-3.0

PATCH In review Andre McCurdy 2 participants 3 messages May 12, 2018 – May 14, 2018

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 default-distrovars.inc: drop obsolete LGPLv2_WHITELIST_GPL-3.0

There doesn't seem to be a clear reason to have two separate variables to hold whitelisted GPLv3 recipes. Both variables are treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is already equivalent to adding it to WHITELIST_GPL-3.0.

Anyone needing to whitelist a GPLv3 recipe should now just use WHITELIST_GPL-3.0.

---
 meta/classes/base.bbclass                       | 25 ++++++++++++-------------
 meta/classes/multilib.bbclass                   | 12 +++++-------
 meta/conf/distro/include/default-distrovars.inc |  1 -
 3 files changed, 17 insertions(+), 21 deletions(-)
meta/classes/base.bbclass +12 -13
index bd0d6e3..68626d5 100644
@@ -529,19 +529,18 @@ python () {
             incompatwl = []
             for lic in bad_licenses:
                 spdx_license = return_spdx(d, lic)
-                for w in ["LGPLv2_WHITELIST_", "WHITELIST_"]:
-                    whitelist.extend((d.getVar(w + lic) or "").split())
-                    if spdx_license:
-                        whitelist.extend((d.getVar(w + spdx_license) or "").split())
-                    '''
-                    We need to track what we are whitelisting and why. If pn is
-                    incompatible we need to be able to note that the image that
-                    is created may infact contain incompatible licenses despite
-                    INCOMPATIBLE_LICENSE being set.
-                    '''
-                    incompatwl.extend((d.getVar(w + lic) or "").split())
-                    if spdx_license:
-                        incompatwl.extend((d.getVar(w + spdx_license) or "").split())
+                whitelist.extend((d.getVar("WHITELIST_" + lic) or "").split())
+                if spdx_license:
+                    whitelist.extend((d.getVar("WHITELIST_" + spdx_license) or "").split())
+                '''
+                We need to track what we are whitelisting and why. If pn is
+                incompatible we need to be able to note that the image that
+                is created may infact contain incompatible licenses despite
+                INCOMPATIBLE_LICENSE being set.
+                '''
+                incompatwl.extend((d.getVar("WHITELIST_" + lic) or "").split())
+                if spdx_license:
+                    incompatwl.extend((d.getVar("WHITELIST_" + spdx_license) or "").split())
 
             if not pn in whitelist:
                 pkgs = d.getVar('PACKAGES').split()
meta/classes/multilib.bbclass +5 -7
index 816f54e..4636c20 100644
@@ -49,7 +49,6 @@ python multilib_virtclass_handler () {
     if bb.data.inherits_class('allarch', e.data) and not bb.data.inherits_class('packagegroup', e.data):
         raise bb.parse.SkipPackage("Don't extend allarch recipes which are not packagegroups")
 
-
     # Expand this since this won't work correctly once we set a multilib into place
     e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS", e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS"))
  
@@ -65,12 +64,11 @@ python multilib_virtclass_handler () {
     e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
 
-    # Expand the WHITELISTs with multilib prefix
-    for whitelist in ["WHITELIST_GPL-3.0", "LGPLv2_WHITELIST_GPL-3.0"]:
-        pkgs = e.data.getVar(whitelist)
-        for pkg in pkgs.split():
-            pkgs += " " + variant + "-" + pkg
-        e.data.setVar(whitelist, pkgs)
+    # Expand WHITELIST_GPL-3.0 with multilib prefix
+    pkgs = e.data.getVar("WHITELIST_GPL-3.0")
+    for pkg in pkgs.split():
+        pkgs += " " + variant + "-" + pkg
+    e.data.setVar("WHITELIST_GPL-3.0", pkgs)
 
     # DEFAULTTUNE can change TARGET_ARCH override so expand this now before update_data
     newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)
meta/conf/distro/include/default-distrovars.inc +0 -1
index 76d09af..2f46e13 100644
@@ -24,7 +24,6 @@ DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}"
 IMAGE_FEATURES ?= ""
 
 WHITELIST_GPL-3.0 ?= ""
-LGPLv2_WHITELIST_GPL-3.0 ?= ""
 
 COMMERCIAL_AUDIO_PLUGINS ?= ""
 # COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"
Signature · 1 line
1.9.1
#1 lore raw
Quoted 10 lines · Andre McCurdy

There doesn't seem to be a clear reason to have two separate variables to hold whitelisted GPLv3 recipes. Both variables are treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is already equivalent to adding it to WHITELIST_GPL-3.0.

Anyone needing to whitelist a GPLv3 recipe should now just use WHITELIST_GPL-3.0.

---

...

meta/conf/distro/include/default-distrovars.inc DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}" · line 27

Quoted 9 lines
meta/conf/distro/include/default-distrovars.inc +0 -1
index 76d09af..2f46e13 100644
@@ -24,7 +24,6 @@ DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}"
 IMAGE_FEATURES ?= ""
 
 WHITELIST_GPL-3.0 ?= ""
-LGPLv2_WHITELIST_GPL-3.0 ?= ""

I don't have enough context to know if this matters, but there are a number of GPLv3 tools, that have LGPLv2 libraries. I believe this whitelist was added to specifically allow this these items to be present on the system, as it was a distinctly different use-case then just the GPL-3.0 version.

(Not sure how relevant that still is. Is there any documentation in either the documentation.conf or guide?)

--Mark

Quoted 3 lines
meta/conf/distro/include/default-distrovars.inc +0 -0
 COMMERCIAL_AUDIO_PLUGINS ?= ""
 # COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"
 
#2 lore raw
Quoted 29 lines · Mark Hatle
Quoted 10 lines · Andre McCurdy

There doesn't seem to be a clear reason to have two separate variables to hold whitelisted GPLv3 recipes. Both variables are treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is already equivalent to adding it to WHITELIST_GPL-3.0.

Anyone needing to whitelist a GPLv3 recipe should now just use WHITELIST_GPL-3.0.

---

...

meta/conf/distro/include/default-distrovars.inc DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}" · line 27

Quoted 9 lines
meta/conf/distro/include/default-distrovars.inc +0 -1
index 76d09af..2f46e13 100644
@@ -24,7 +24,6 @@ DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${DISTRO_FEATURES_LIBC}"
 IMAGE_FEATURES ?= ""
 
 WHITELIST_GPL-3.0 ?= ""
-LGPLv2_WHITELIST_GPL-3.0 ?= ""

I don't have enough context to know if this matters, but there are a number of GPLv3 tools, that have LGPLv2 libraries. I believe this whitelist was added to specifically allow this these items to be present on the system, as it was a distinctly different use-case then just the GPL-3.0 version.

Quoted 2 lines

(Not sure how relevant that still is. Is there any documentation in either the documentation.conf or guide?)

That used to be relevant a while ago when LICENSE was applied to all packages created by the recipe. Nowadays, LICENSE can be defined on a per-package basis, so the case where a recipe builds (for example) an LPGLv2 library and a GPLv3 demo app and an image in a GPLv3-free distro needs to include only the library is handled fine without any whitelisting. The cairo and gnutls recipes are examples of that in oe-core.