From 6cb930c0ead4fc1a9f80a8094ddc79ef56ad2276 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 7 Mar 2018 12:08:00 -0800 Subject: dev-manual: Added section on manually upgrading recipes (From yocto-docs rev: b5515ad6f4b5653095e338114607dd11a11181df) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 95 +++++++++++++++++++++- 1 file changed, 94 insertions(+), 1 deletion(-) (limited to 'documentation/dev-manual/dev-manual-common-tasks.xml') diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 8264331dd1..306ba6d580 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -4156,7 +4156,7 @@ - Clone the AUH Respository: + Clone the AUH Repository: To use AUH, you must clone the repository onto your development host. The following command uses Git to create a local @@ -4521,6 +4521,99 @@
Manually Upgrading a Recipe + + If for some reason you choose not to upgrade recipes using the + Auto Upgrade Helper (AUH) + or by using + devtool upgrade, + you can manually edit the recipe files to upgrade the versions. + Caution + Manually updating multiple recipes scales poorly and + involves many steps. + The recommendation to upgrade recipe versions is through + AUH or devtool upgrade, both of which + automate some steps and provide guidance for others needed + for the manual process. + + + + + To manually upgrade recipe versions, follow these general steps: + + + Change the Recipe Name: + Adjust the version (i.e. + PV) + part of the recipe name such that it uses the + new version number. + + + Update SRCREV if Needed: + If the source code your recipe builds is fetched from + Git or some other Version Control System (VCS), + update + SRCREV + to point to the commit hash that matches the new + version. + + + Build the Software: + Try to build the recipe using BitBake. + Typical build failures include the following: + + + License terms were updated for the new version. + For this case, you need to review the new + terms of the license and update the values of + LICENSE + and + LIC_FILES_CHKSUM + as needed. + + + Custom patches carried by the older version of + the recipe might fail to apply to the new + version. + For these cases, you need to review the + failures. + Patches might not be necessary for the new + version of the software if the upgraded version + has fixed those issues. + If a patch is necessary and failing, you need + to rebase it into the new version. + + + + + Optionally Attempt to Build for Several Architectures: + Once you successfully build the new software for a + given architecture, you could test the build for + other architectures by changing the + MACHINE + variable and rebuilding the software. + This optional step is especially important if the + recipe is public. + + + Check the Upstream Change Log or Release Notes: + Checking both these reveals if new features exist that + could break backwards-compatibility. + If so, you need to take steps to mitigate or eliminate + that situation. + + + Optionally Create a Bootable Image and Test: + If you want, you can test the new software by booting + it onto actual hardware. + + + Create a Commit with the Change in the Layer Repository: + After all builds work and any testing is successful, + you can create commits for any changes in the layer + holding your upgraded recipe. + + +
-- cgit v1.2.3-54-g00ecf