diff options
Diffstat (limited to 'documentation/dev-manual/common-tasks.rst')
-rw-r--r-- | documentation/dev-manual/common-tasks.rst | 44 |
1 files changed, 22 insertions, 22 deletions
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst index 9a6416bf8e..e71c352549 100644 --- a/documentation/dev-manual/common-tasks.rst +++ b/documentation/dev-manual/common-tasks.rst | |||
@@ -11037,17 +11037,17 @@ name and version (after variable expansion):: | |||
11037 | In order for a component restricted by a | 11037 | In order for a component restricted by a |
11038 | :term:`LICENSE_FLAGS` definition to be enabled and included in an image, it | 11038 | :term:`LICENSE_FLAGS` definition to be enabled and included in an image, it |
11039 | needs to have a matching entry in the global | 11039 | needs to have a matching entry in the global |
11040 | :term:`LICENSE_FLAGS_WHITELIST` | 11040 | :term:`LICENSE_FLAGS_ACCEPTED` |
11041 | variable, which is a variable typically defined in your ``local.conf`` | 11041 | variable, which is a variable typically defined in your ``local.conf`` |
11042 | file. For example, to enable the | 11042 | file. For example, to enable the |
11043 | ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you | 11043 | ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you |
11044 | could add either the string "commercial_gst-plugins-ugly" or the more | 11044 | could add either the string "commercial_gst-plugins-ugly" or the more |
11045 | general string "commercial" to :term:`LICENSE_FLAGS_WHITELIST`. See the | 11045 | general string "commercial" to :term:`LICENSE_FLAGS_ACCEPTED`. See the |
11046 | ":ref:`dev-manual/common-tasks:license flag matching`" section for a full | 11046 | ":ref:`dev-manual/common-tasks:license flag matching`" section for a full |
11047 | explanation of how :term:`LICENSE_FLAGS` matching works. Here is the | 11047 | explanation of how :term:`LICENSE_FLAGS` matching works. Here is the |
11048 | example:: | 11048 | example:: |
11049 | 11049 | ||
11050 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly" | 11050 | LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly" |
11051 | 11051 | ||
11052 | Likewise, to additionally enable the package built from the recipe | 11052 | Likewise, to additionally enable the package built from the recipe |
11053 | containing ``LICENSE_FLAGS = "license_${PN}_${PV}"``, and assuming that | 11053 | containing ``LICENSE_FLAGS = "license_${PN}_${PV}"``, and assuming that |
@@ -11055,7 +11055,7 @@ the actual recipe name was ``emgd_1.10.bb``, the following string would | |||
11055 | enable that package as well as the original ``gst-plugins-ugly`` | 11055 | enable that package as well as the original ``gst-plugins-ugly`` |
11056 | package:: | 11056 | package:: |
11057 | 11057 | ||
11058 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10" | 11058 | LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly license_emgd_1.10" |
11059 | 11059 | ||
11060 | As a convenience, you do not need to specify the | 11060 | As a convenience, you do not need to specify the |
11061 | complete license string for every package. You can use | 11061 | complete license string for every package. You can use |
@@ -11068,7 +11068,7 @@ previously mentioned as well as any other packages that have licenses | |||
11068 | starting with "commercial" or "license". | 11068 | starting with "commercial" or "license". |
11069 | :: | 11069 | :: |
11070 | 11070 | ||
11071 | LICENSE_FLAGS_WHITELIST = "commercial license" | 11071 | LICENSE_FLAGS_ACCEPTED = "commercial license" |
11072 | 11072 | ||
11073 | License Flag Matching | 11073 | License Flag Matching |
11074 | ~~~~~~~~~~~~~~~~~~~~~ | 11074 | ~~~~~~~~~~~~~~~~~~~~~ |
@@ -11076,7 +11076,7 @@ License Flag Matching | |||
11076 | License flag matching allows you to control what recipes the | 11076 | License flag matching allows you to control what recipes the |
11077 | OpenEmbedded build system includes in the build. Fundamentally, the | 11077 | OpenEmbedded build system includes in the build. Fundamentally, the |
11078 | build system attempts to match :term:`LICENSE_FLAGS` strings found in | 11078 | build system attempts to match :term:`LICENSE_FLAGS` strings found in |
11079 | recipes against strings found in :term:`LICENSE_FLAGS_WHITELIST`. | 11079 | recipes against strings found in :term:`LICENSE_FLAGS_ACCEPTED`. |
11080 | A match causes the build system to include a recipe in the | 11080 | A match causes the build system to include a recipe in the |
11081 | build, while failure to find a match causes the build system to exclude | 11081 | build, while failure to find a match causes the build system to exclude |
11082 | a recipe. | 11082 | a recipe. |
@@ -11085,19 +11085,19 @@ In general, license flag matching is simple. However, understanding some | |||
11085 | concepts will help you correctly and effectively use matching. | 11085 | concepts will help you correctly and effectively use matching. |
11086 | 11086 | ||
11087 | Before a flag defined by a particular recipe is tested against the | 11087 | Before a flag defined by a particular recipe is tested against the |
11088 | entries of :term:`LICENSE_FLAGS_WHITELIST`, the expanded | 11088 | entries of :term:`LICENSE_FLAGS_ACCEPTED`, the expanded |
11089 | string ``_${PN}`` is appended to the flag. This expansion makes each | 11089 | string ``_${PN}`` is appended to the flag. This expansion makes each |
11090 | :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the | 11090 | :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the |
11091 | string is then matched against the entries. Thus, specifying | 11091 | string is then matched against the entries. Thus, specifying |
11092 | ``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results | 11092 | ``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results |
11093 | in the string ``"commercial_foo"``. And, to create a match, that string | 11093 | in the string ``"commercial_foo"``. And, to create a match, that string |
11094 | must appear among the entries of :term:`LICENSE_FLAGS_WHITELIST`. | 11094 | must appear among the entries of :term:`LICENSE_FLAGS_ACCEPTED`. |
11095 | 11095 | ||
11096 | Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the | 11096 | Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the |
11097 | :term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for | 11097 | :term:`LICENSE_FLAGS_ACCEPTED` variable allows you a lot of flexibility for |
11098 | including or excluding recipes based on licensing. For example, you can | 11098 | including or excluding recipes based on licensing. For example, you can |
11099 | broaden the matching capabilities by using license flags string subsets | 11099 | broaden the matching capabilities by using license flags string subsets |
11100 | in :term:`LICENSE_FLAGS_WHITELIST`. | 11100 | in :term:`LICENSE_FLAGS_ACCEPTED`. |
11101 | 11101 | ||
11102 | .. note:: | 11102 | .. note:: |
11103 | 11103 | ||
@@ -11106,7 +11106,7 @@ in :term:`LICENSE_FLAGS_WHITELIST`. | |||
11106 | ``usethispart_1.3``, ``usethispart_1.4``, and so forth). | 11106 | ``usethispart_1.3``, ``usethispart_1.4``, and so forth). |
11107 | 11107 | ||
11108 | For example, simply specifying the string "commercial" in the | 11108 | For example, simply specifying the string "commercial" in the |
11109 | :term:`LICENSE_FLAGS_WHITELIST` variable matches any expanded | 11109 | :term:`LICENSE_FLAGS_ACCEPTED` variable matches any expanded |
11110 | :term:`LICENSE_FLAGS` definition that starts with the string | 11110 | :term:`LICENSE_FLAGS` definition that starts with the string |
11111 | "commercial" such as "commercial_foo" and "commercial_bar", which | 11111 | "commercial" such as "commercial_foo" and "commercial_bar", which |
11112 | are the strings the build system automatically generates for | 11112 | are the strings the build system automatically generates for |
@@ -11124,24 +11124,24 @@ This scheme works even if the :term:`LICENSE_FLAGS` string already has | |||
11124 | ``_${PN}`` appended. For example, the build system turns the license | 11124 | ``_${PN}`` appended. For example, the build system turns the license |
11125 | flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match | 11125 | flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match |
11126 | both the general "commercial" and the specific "commercial_1.2_foo" | 11126 | both the general "commercial" and the specific "commercial_1.2_foo" |
11127 | strings found in the :term:`LICENSE_FLAGS_WHITELIST` variable, as expected. | 11127 | strings found in the :term:`LICENSE_FLAGS_ACCEPTED` variable, as expected. |
11128 | 11128 | ||
11129 | Here are some other scenarios: | 11129 | Here are some other scenarios: |
11130 | 11130 | ||
11131 | - You can specify a versioned string in the recipe such as | 11131 | - You can specify a versioned string in the recipe such as |
11132 | "commercial_foo_1.2" in a "foo" recipe. The build system expands this | 11132 | "commercial_foo_1.2" in a "foo" recipe. The build system expands this |
11133 | string to "commercial_foo_1.2_foo". Combine this license flag with a | 11133 | string to "commercial_foo_1.2_foo". Combine this license flag with a |
11134 | :term:`LICENSE_FLAGS_WHITELIST` variable that has the string | 11134 | :term:`LICENSE_FLAGS_ACCEPTED` variable that has the string |
11135 | "commercial" and you match the flag along with any other flag that | 11135 | "commercial" and you match the flag along with any other flag that |
11136 | starts with the string "commercial". | 11136 | starts with the string "commercial". |
11137 | 11137 | ||
11138 | - Under the same circumstances, you can add "commercial_foo" in the | 11138 | - Under the same circumstances, you can add "commercial_foo" in the |
11139 | :term:`LICENSE_FLAGS_WHITELIST` variable and the build system not only | 11139 | :term:`LICENSE_FLAGS_ACCEPTED` variable and the build system not only |
11140 | matches "commercial_foo_1.2" but also matches any license flag with | 11140 | matches "commercial_foo_1.2" but also matches any license flag with |
11141 | the string "commercial_foo", regardless of the version. | 11141 | the string "commercial_foo", regardless of the version. |
11142 | 11142 | ||
11143 | - You can be very specific and use both the package and version parts | 11143 | - You can be very specific and use both the package and version parts |
11144 | in the :term:`LICENSE_FLAGS_WHITELIST` list (e.g. | 11144 | in the :term:`LICENSE_FLAGS_ACCEPTED` list (e.g. |
11145 | "commercial_foo_1.2") to specifically match a versioned recipe. | 11145 | "commercial_foo_1.2") to specifically match a versioned recipe. |
11146 | 11146 | ||
11147 | Other Variables Related to Commercial Licenses | 11147 | Other Variables Related to Commercial Licenses |
@@ -11163,20 +11163,20 @@ file:: | |||
11163 | gst-plugins-ugly-mpegaudioparse" | 11163 | gst-plugins-ugly-mpegaudioparse" |
11164 | COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \ | 11164 | COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \ |
11165 | gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" | 11165 | gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" |
11166 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" | 11166 | LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" |
11167 | 11167 | ||
11168 | 11168 | ||
11169 | Of course, you could also create a matching list for those | 11169 | Of course, you could also create a matching list for those |
11170 | components using the more general "commercial" in the | 11170 | components using the more general "commercial" in the |
11171 | :term:`LICENSE_FLAGS_WHITELIST` variable, but that would also enable all | 11171 | :term:`LICENSE_FLAGS_ACCEPTED` variable, but that would also enable all |
11172 | the other packages with :term:`LICENSE_FLAGS` | 11172 | the other packages with :term:`LICENSE_FLAGS` |
11173 | containing "commercial", which you may or may not want:: | 11173 | containing "commercial", which you may or may not want:: |
11174 | 11174 | ||
11175 | LICENSE_FLAGS_WHITELIST = "commercial" | 11175 | LICENSE_FLAGS_ACCEPTED = "commercial" |
11176 | 11176 | ||
11177 | Specifying audio and video plugins as part of the | 11177 | Specifying audio and video plugins as part of the |
11178 | ``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements | 11178 | ``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements |
11179 | (along with the enabling :term:`LICENSE_FLAGS_WHITELIST`) includes the | 11179 | (along with the enabling :term:`LICENSE_FLAGS_ACCEPTED`) includes the |
11180 | plugins or components into built images, thus adding support for media | 11180 | plugins or components into built images, thus adding support for media |
11181 | formats or components. | 11181 | formats or components. |
11182 | 11182 | ||
@@ -11540,7 +11540,7 @@ The NIST database knows which versions are vulnerable and which ones | |||
11540 | are not. | 11540 | are not. |
11541 | 11541 | ||
11542 | Last but not least, you can choose to ignore vulnerabilities through | 11542 | Last but not least, you can choose to ignore vulnerabilities through |
11543 | the :term:`CVE_CHECK_PN_WHITELIST` and :term:`CVE_CHECK_WHITELIST` | 11543 | the :term:`CVE_CHECK_SKIP_RECIPE` and :term:`CVE_CHECK_IGNORE` |
11544 | variables. | 11544 | variables. |
11545 | 11545 | ||
11546 | Implementation details | 11546 | Implementation details |
@@ -11559,9 +11559,9 @@ Then, the code looks up all the CVE IDs in the NIST database for all the | |||
11559 | products defined in :term:`CVE_PRODUCT`. Then, for each found CVE: | 11559 | products defined in :term:`CVE_PRODUCT`. Then, for each found CVE: |
11560 | 11560 | ||
11561 | - If the package name (:term:`PN`) is part of | 11561 | - If the package name (:term:`PN`) is part of |
11562 | :term:`CVE_CHECK_PN_WHITELIST`, it is considered as patched. | 11562 | :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as patched. |
11563 | 11563 | ||
11564 | - If the CVE ID is part of :term:`CVE_CHECK_WHITELIST`, it is | 11564 | - If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is |
11565 | considered as patched too. | 11565 | considered as patched too. |
11566 | 11566 | ||
11567 | - If the CVE ID is part of the patched CVE for the recipe, it is | 11567 | - If the CVE ID is part of the patched CVE for the recipe, it is |