mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-06-02 01:19:52 +00:00
Code Issues Projects Releases Wiki Activity

migration-4.3: adjustments to existing text

Browse Source 
* Reword the layername side-effects commentary to be a bit more readable
* Extend edgerouter removal description
* Correct capitalisation of systemd
* For QEMU_USE_SLIRP, specify what to use instead, and adjust the
  following list item to use the same style
* Extend statement on -crossssdk / MLPREFIX change to indicate what
  needs to be done

(From yocto-docs rev: bfc49b59b6cd905cef0294792f05661b36181a6e)

Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Paul Eggleton
2023-11-06 23:29:41 +13:00
committed by Richard Purdie
parent fe98b96022
commit 99926a4052
1 changed files with 15 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/migration-guides/migration-4.3.rst
+15 -10
View File
@@ -34,9 +34,9 @@ Layername override implications
Code can now know which layer a recipe is coming from through the newly added Code can now know which layer a recipe is coming from through the newly added
:term:`FILE_LAYERNAME` variable and the ``layer-<layername> override``. This is being used :term:`FILE_LAYERNAME` variable and the ``layer-<layername> override``. This is being used
for enabling QA checks on a per layer basis. For existing code this has the for enabling QA checks on a per layer basis. For existing code this has the
side effect that the QA checks will apply to things being bbappended to recipes side effect that the QA checks will apply to recipes being bbappended
from other layers. Those other layers would need to have patch upstream status from other layers - for example, patches added through such bbappends will now
entries for patches being bbappended for example. need to have the "Upstream-Status" specified in the patch header.
.. _migration-4.3-compiling-changes: .. _migration-4.3-compiling-changes:
@@ -71,10 +71,13 @@ See :ref:`all supported distributions <system-requirements-supported-distros>`.
.. _migration-4.3-removed-machines: .. _migration-4.3-removed-machines:
Removed machines edgerouter machine removed
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``edgerouter`` BSP in ``meta-yocto-bsp`` has been removed. The ``edgerouter`` reference BSP for the MIPS architecture in ``meta-yocto-bsp``
has been removed as the hardware has been unavailable for some time. There is no
suitable reference MIPS hardware to replace it with, but the MIPS architecture
will continue to get coverage via QEMU build/boot testing.
.. _migration-4.3-go-changes: .. _migration-4.3-go-changes:
@@ -86,7 +89,7 @@ Go language changes
.. _migration-4.3-systemd-changes: .. _migration-4.3-systemd-changes:
Systemd changes systemd changes
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
Upstream systemd is now more strict on filesystem layout and the ``usrmerge`` Upstream systemd is now more strict on filesystem layout and the ``usrmerge``
@@ -120,8 +123,8 @@ The following variables have been removed:
- ``AUTHOR`` - ``AUTHOR``
- ``PERLARCH`` - ``PERLARCH``
- ``PERLVERSION`` - ``PERLVERSION``
- ``QEMU_USE_SLIRP`` - ``QEMU_USE_SLIRP`` - add ``slirp`` to ``TEST_RUNQEMUPARAMS`` instead.
- ``SERIAL_CONSOLES_CHECK``, which is no longer necessary because all - ``SERIAL_CONSOLES_CHECK`` - no longer necessary because all
consoles listed in :term:`SERIAL_CONSOLES` are checked for their existence consoles listed in :term:`SERIAL_CONSOLES` are checked for their existence
before a ``getty`` is started. before a ``getty`` is started.
@@ -168,5 +171,7 @@ Miscellaneous changes
``virtual/XXX`` provider/dependencies where a ``PREFIX`` was used as well, ``virtual/XXX`` provider/dependencies where a ``PREFIX`` was used as well,
as we don't need both and it made automated dependency rewriting as we don't need both and it made automated dependency rewriting
unnecessarily complex. In general this only affects internal toolchain unnecessarily complex. In general this only affects internal toolchain
dependencies so isn't end user visible. dependencies so isn't end user visible, but if for some reason you have
custom classes or recipes that rely upon the old providers then you will
need to update those.