1Release 3.3 (hardknott)
2=======================
3
4This section provides migration information for moving to the Yocto
5Project 3.3 Release (codename "hardknott") from the prior release.
6
7
8.. _migration-3.3-minimum-system-requirements:
9
10Minimum system requirements
11---------------------------
12
13You will now need at least Python 3.6 installed on your build host. Most recent
14distributions provide this, but should you be building on a distribution that
15does not have it, you can use the ``buildtools-tarball`` (easily installable
16using ``scripts/install-buildtools``) - see
17:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
18for details.
19
20
21.. _migration-3.3-removed-recipes:
22
23Removed recipes
24---------------
25
26The following recipes have been removed:
27
28- ``go-dep``: obsolete with the advent of go modules
29- ``gst-validate``: replaced by ``gst-devtools``
30- ``linux-yocto``: removed 5.8 version recipes (5.4 / 5.10 still provided)
31- ``vulkan-demos``: replaced by ``vulkan-samples``
32
33
34.. _migration-3.3-common-license-only-versions:
35
36Single version common license file naming
37-----------------------------------------
38
39Some license files in ``meta/files/common-licenses`` have been renamed to match
40current SPDX naming conventions:
41
42- AGPL-3.0 -> AGPL-3.0-only
43- GPL-1.0 -> GPL-1.0-only
44- GPL-2.0 -> GPL-2.0-only
45- GPL-3.0 -> GPL-3.0-only
46- LGPL-2.0 -> LGPL-2.0-only
47- LGPL-2.1 -> LGPL-2.1-only
48- LGPL-3.0 -> LGPL-3.0-only
49
50Additionally, corresponding "-or-later" suffixed files have been added e.g.
51``GPL-2.0-or-later``.
52
53It is not required that you change :term:`LICENSE` values as there are mappings
54from the original names in place; however, in rare cases where you have a recipe
55which sets :term:`LIC_FILES_CHKSUM` to point to file(s) in
56``meta/files/common-licenses`` (which in any case is not recommended) you will
57need to update those.
58
59
60.. _migration-3.3-python3targetconfig:
61
62New ``python3targetconfig`` class
63---------------------------------
64
65A new :ref:`python3targetconfig <ref-classes-python3targetconfig>` class has been
66created for situations where you would previously have inherited the
67:ref:`python3native <ref-classes-python3native>` class but need access to target configuration data (such as
68correct installation directories). Recipes where this situation applies should
69be changed to inherit ``python3targetconfig`` instead of ``python3native``. This
70also adds a dependency on target ``python3``, so it should only be used where
71appropriate in order to avoid unnecessarily lengthening builds.
72
73Some example recipes where this change has been made: ``gpgme``, ``libcap-ng``,
74``python3-pycairo``.
75
76
77.. _migration-3.3-distutils-path:
78
79``setup.py`` path for python modules
80------------------------------------
81
82In a Python module, sometimes ``setup.py`` can be buried deep in the
83source tree. Previously this was handled in recipes by setting :term:`S` to
84point to the subdirectory within the source where ``setup.py`` is located.
85However with the recent :ref:`pseudo <overview-manual/concepts:fakeroot and pseudo>`
86changes, some Python modules make changes to files beneath ``${S}``, for
87example::
88
89   S = "${WORKDIR}/git/python/pythonmodule"
90
91then in ``setup.py`` it works with source code in a relative fashion, such
92as ``../../src``. This causes pseudo to fail as it isn't able to track
93the paths properly. This release introduces a new ``DISTUTILS_SETUP_PATH``
94variable so that recipes can specify it explicitly, for example::
95
96   S = "${WORKDIR}/git"
97   DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule"
98
99Recipes that inherit from ``distutils3`` (or
100:ref:`setuptools3 <ref-classes-setuptools3>` which itself inherits
101``distutils3``) that also set :term:`S` to
102point to a Python module within a subdirectory in the aforementioned
103manner should be changed to set ``DISTUTILS_SETUP_PATH`` instead.
104
105
106.. _migration-3.3-bitbake:
107
108BitBake changes
109---------------
110
111- BitBake is now configured to use a default ``umask`` of ``022`` for all tasks
112  (specified via a new :term:`BB_DEFAULT_UMASK` variable). If needed, ``umask`` can
113  still be set on a per-task basis via the ``umask`` varflag on the task
114  function, but that is unlikely to be necessary in most cases.
115
116- If a version specified in :term:`PREFERRED_VERSION` is not available this
117  will now trigger a warning instead of just a note, making such issues more
118  visible.
119
120
121.. _migration-3.3-packaging:
122
123Packaging changes
124-----------------
125
126The following packaging changes have been made; in all cases the main package
127still depends upon the split out packages so you should not need to do anything
128unless you want to take advantage of the improved granularity:
129
130- ``dbus``: ``-common`` and ``-tools`` split out
131- ``iproute2``: split ``ip`` binary to its own package
132- ``net-tools``: split ``mii-tool`` into its own package
133- ``procps``: split ``ps`` and ``sysctl`` into their own packages
134- ``rpm``: split build and extra functionality into separate packages
135- ``sudo``: split ``sudo`` binary into ``sudo-sudo`` and libs into ``sudo-lib``
136- ``systemtap``: examples, python scripts and runtime material split out
137- ``util-linux``: ``libuuid`` has been split out to its own
138  ``util-linux-libuuid`` recipe (and corresponding packages) to avoid circular
139  dependencies if ``libgcrypt`` support is enabled in ``util-linux``.
140  (``util-linux`` depends upon ``util-linux-libuuid``.)
141
142
143.. _migration-3.3-misc:
144
145Miscellaneous changes
146---------------------
147
148- The default poky :term:`DISTRO_VERSION` value now uses the core metadata's
149  git hash (i.e. :term:`METADATA_REVISION`) rather than the date (i.e.
150  :term:`DATE`) to reduce one small source of non-reproducibility. You can
151  of course specify your own :term:`DISTRO_VERSION` value as desired
152  (particularly if you create your own custom distro configuration).
153- ``adwaita-icon-theme`` version 3.34.3 has been added back, and is selected
154  as the default via :term:`PREFERRED_VERSION` in
155  ``meta/conf/distro/include/default-versions.inc`` due to newer versions
156  not working well with ``librsvg`` 2.40. ``librsvg`` is not practically
157  upgradeable at the moment as it has been ported to Rust, and Rust is not
158  (yet) in OE-Core, but this will change in a future release.
159- ``ffmpeg`` is now configured to disable GPL-licensed portions by default
160  to make it harder to accidentally violate the GPL. To explicitly enable GPL
161  licensed portions, add ``gpl`` to :term:`PACKAGECONFIG` for ``ffmpeg``
162  using a bbappend (or use ``PACKAGECONFIG_append_pn-ffmpeg = " gpl"`` in
163  your configuration.)
164- ``connman`` is now set to conflict with ``systemd-networkd`` as they
165  overlap functionally and may interfere with each other at runtime.
166- Canonical SPDX license names are now used in image license manifests in
167  order to avoid aliases of the same license from showing up together (e.g.
168  ``GPLv2`` and ``GPL-2.0``)
169