summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/python/python_2.7.16.bb
diff options
context:
space:
mode:
authorAlexander Kanavin <alex.kanavin@gmail.com>2019-10-10 13:18:48 +0200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2019-10-15 14:16:10 +0100
commit25df405d4b019ba6444d03598e914ff2efdad4c9 (patch)
tree5c716fbd16cf71553014af461f6fc922aed01bcf /meta/recipes-devtools/python/python_2.7.16.bb
parentf46b73658ee6697338d0431efa9cc33fd2c9b914 (diff)
downloadpoky-25df405d4b019ba6444d03598e914ff2efdad4c9.tar.gz
license_image.bbclass: check and reject packages which have incompatible licenses
The use case is setting INCOMPATIBLE_LICENSE per image, rather than as an awkward, and too strict global setting. This for example would allow building development images with gplv3 tools, but production images without them, and checking that nothing gpl3-licensed gets into the latter. Examples are provided via the selftest: four scenarios are tested: - bash is added to the image, with a default gpl3 license; this is rejected - bash is added to the image, with a "gpl3 & other" license; this is also rejected - bash is added to the image, with a "gpl3 | other" license; this is accepted, but only 'other' is added to the license manifest (this was already handled correctly previously). - bash is added to the image with a default gpl3 license, and is additionally whitelisted for that image; this is accepted. Eventually, this would allow deprecating the meta-gplv2 layer, while still enforcing the no-gpl3 rule where possible and needed. (From OE-Core rev: fd50395bc0783a3cce7b5b0d7398f22783ebbeca) Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-devtools/python/python_2.7.16.bb')
0 files changed, 0 insertions, 0 deletions