MIRRORS/poky
1
0
Fork 0
mirror of git://git.yoctoproject.org/poky.git synced 2025-07-19 12:59:02 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

migration-guides/{migration,release-note}-5.2: update for 5.2 release

Browse Source 
Document changes between 1c3020f173 ("expat: Upgrade 2.7.0 -> 2.7.1")
up to e894acce6e ("build-appliance-image: Update to master head
revision") in Poky:

- Add a note on the devtool upgrade-status change.
- Be more precise about the usage of multiple repositories in SRC_URI,
  mention that it makes sense for bare clones only.

As the walnascar branch has now frozen and is up for QA, these should be
the one of the last changes to these documents.

(From yocto-docs rev: 322355ead2be9e267368ca47d805f41ae10ad6cc)

Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Antonin Godard 2025-04-07 10:59:20 +02:00 committed by Richard Purdie
parent 15a7d7b881
commit 90e4af3eff
2 changed files with 13 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
documentation/migration-guides/migration-5.2.rst
View File

@ -186,18 +186,20 @@ The support for having multiple Git revisions per URL in :term:`SRC_URI` was
removed from BitBake, which means the following syntax is not supported removed from BitBake, which means the following syntax is not supported
anymore:: anymore::
SRC_URI = "git://some.host/somepath;branch=branchX,branchY;name=nameX,nameY" SRC_URI = "git://some.host/somepath;bareclone=1;branch=branchX,branchY;name=nameX,nameY"
SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx" SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx"
SRCREV_nameY = "yyyyyyyyyyyyyyyyyyyy" SRCREV_nameY = "yyyyyyyyyyyyyyyyyyyy"
This was rarely used in the core repositories, and this removal simplifies the This was rarely used in the core repositories because it would only ever make
code logic in several places. sense for bare clones (the ``bareclone=1`` :term:`SRC_URI` option) where recipes
take care of the Git checkout. This removal simplifies the code logic in several
places.
If one of your recipes is still using this mechanism, you can split the If one of your recipes is using this mechanism, you can split the code source
code source fetching into two separate entries:: fetching into two separate entries::
SRC_URI = "git://some.host/somepath;branch=branchX;name=nameX \ SRC_URI = "git://some.host/somepath;bareclone=1;branch=branchX;name=nameX \
git://some.host/somepath;branch=branchY;name=nameY" git://some.host/somepath;bareclone=1;branch=branchY;name=nameY"
SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx" SRCREV_nameX = "xxxxxxxxxxxxxxxxxxxx"
SRCREV_nameY = "yyyyyyyyyyyyyyyyyyyy" SRCREV_nameY = "yyyyyyyyyyyyyyyyyyyy"

4
documentation/migration-guides/release-notes-5.2.rst
View File

@ -447,6 +447,10 @@ New Features / Enhancements in |yocto-ver|
with a matching hash and path, it will be linked, otherwise a new File with a matching hash and path, it will be linked, otherwise a new File
element will be created. element will be created.
- The output of :ref:`devtool upgrade-status
<ref-manual/devtool-reference:Checking on the Upgrade Status of a Recipe>`
is now sorted by recipe name.
- Patchtest-related changes: - Patchtest-related changes:
- Refactor pattern definitions in a ``patterns`` module. - Refactor pattern definitions in a ``patterns`` module.