[PATCH 0/3] Additional migration info for 3.2

[PATCH 0/3] Additional migration info for 3.2

[Paul Eggleton]

These patches should be applied after the set I sent earlier today.


The following changes since commit 18956e99fafa0d898c37a785e44015af2eb532d8:

  ref-manual: add migration section for 3.2 (2020-10-27 15:58:19 -0700)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib paule/migration-3.2-fixup
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/migration-3.2-fixup

Paul Eggleton (3):
  ref-manual: add IMAGE_LINK_NAME
  ref-manual: add migration info for image-artifact-names
  ref-manual: add migration info about MLPREFIX changes

 documentation/ref-manual/migration-3.2.rst | 52 ++++++++++++++++++++++++++++++
 documentation/ref-manual/ref-variables.rst | 11 +++++++
 2 files changed, 63 insertions(+)

-- 
1.8.3.1

[PATCH 1/3] ref-manual: add IMAGE_LINK_NAME

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add IMAGE_LINK_NAME to the variable glossary.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/ref-variables.rst | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index a7fb777..a69cf6a 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -3098,6 +3098,17 @@ system and gives an overview of their function and contents.
       See the :term:`GLIBC_GENERATE_LOCALES`
       variable for information on generating GLIBC locales.
 
+
+   :term:`IMAGE_LINK_NAME`
+      The name of the output image symlink (which does not include
+      the version part as :term:`IMAGE_NAME` does). The default value
+      is derived using the :term:`IMAGE_BASENAME` and :term:`MACHINE`
+      variables:
+      ::
+
+         IMAGE_LINK_NAME ?= "${IMAGE_BASENAME}-${MACHINE}"
+
+
    :term:`IMAGE_MANIFEST`
       The manifest file for the image. This file lists all the installed
       packages that make up the image. The file contains package
-- 
1.8.3.1

[PATCH 2/3] ref-manual: add migration info for image-artifact-names

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add some info on the image-artifact-names class change in gatesgarth.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/migration-3.2.rst | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/documentation/ref-manual/migration-3.2.rst b/documentation/ref-manual/migration-3.2.rst
index a56c5d4..3c0ea7b 100644
--- a/documentation/ref-manual/migration-3.2.rst
+++ b/documentation/ref-manual/migration-3.2.rst
@@ -246,6 +246,27 @@ by these image recipes directly then you will need to adapt to the new
 naming without the ``.rootfs`` part.
 
 
+.. _migration-3.2-image-artifact-names:
+
+Image artifact name variables now centralised in image-artifact-names class
+---------------------------------------------------------------------------
+
+The defaults for the following image artifact name variables have been moved
+from bitbake.conf to a new ``image-artifact-names`` class:
+
+- :term:`IMAGE_BASENAME`
+- :term:`IMAGE_LINK_NAME`
+- :term:`IMAGE_NAME`
+- :term:`IMAGE_NAME_SUFFIX`
+- :term:`IMAGE_VERSION_SUFFIX`
+
+Image-related classes now inherit this class, and typically these variables
+are only referenced within image recipes so those will be unaffected by this
+change. However if you have references to these variables in either a recipe
+that is not an image or a class that is enabled globally, then those will
+now need to be changed to ``inherit image-artifact-names``.
+
+
 .. _migration-3.2-misc:
 
 Miscellaneous changes
-- 
1.8.3.1

[PATCH 3/3] ref-manual: add migration info about MLPREFIX changes

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add a migration subsection on the need to add MLPREFIX to conditional
package dependencies in gatesgarth.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/migration-3.2.rst | 31 ++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/documentation/ref-manual/migration-3.2.rst b/documentation/ref-manual/migration-3.2.rst
index 3c0ea7b..b536f8e 100644
--- a/documentation/ref-manual/migration-3.2.rst
+++ b/documentation/ref-manual/migration-3.2.rst
@@ -75,6 +75,37 @@ pseudo will throw an ``abort()`` and direct you to a `wiki page <https://wiki.yo
 that explains how to deal with this.
 
 
+.. _migration-3.2-multilib-mlprefix:
+
+``MLPREFIX`` now required for multilib when runtime dependencies conditionally added
+------------------------------------------------------------------------------------
+
+In order to solve some previously intractable problems with runtime
+dependencies and multilib, a change was made that now requires the :term:`MLPREFIX`
+value to be explicitly prepended to package names being added as
+dependencies (e.g. in :term:`RDEPENDS` and :term:`RRECOMMENDS` values)
+where the dependency is conditionally added.
+
+If you have anonymous python or in-line python conditionally adding
+dependencies in your custom recipes, and you intend for those recipes to
+work with multilib, then you will need to ensure that ``${MLPREFIX}``
+is prefixed on the package names in the dependencies, for example
+(from the ``glibc`` recipe): ::
+
+    RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', '${MLPREFIX}ldconfig', '', d)}"
+
+This also applies when conditionally adding packages to :term:`PACKAGES` where
+those packages have dependencies, for example (from the ``alsa-plugins`` recipe): ::
+
+    PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}"
+    ...
+    RDEPENDS_${PN}-pulseaudio-conf += "\
+            ${MLPREFIX}libasound-module-conf-pulse \
+            ${MLPREFIX}libasound-module-ctl-pulse \
+            ${MLPREFIX}libasound-module-pcm-pulse \
+    "
+
+
 .. _migration-3.2-packagegroup-core-device-devel:
 
 packagegroup-core-device-devel no longer included in images built for qemu* machines
-- 
1.8.3.1