diff options
author | jmbills <jason.m.bills@intel.com> | 2021-08-03 01:45:08 +0300 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-08-03 01:45:08 +0300 |
commit | 10ad77d5bc86709d8ff7f95e7040e39f1c153903 (patch) | |
tree | 307cedb87f4c0a329740c55ac364ed489d1d8fc2 /poky/documentation/migration-guides/migration-general.rst | |
parent | c6b1c6ba7a01b7987d65d61c262c44c320193108 (diff) | |
parent | 67327ddc580cb9a85219a534844832a1682780d4 (diff) | |
download | openbmc-10ad77d5bc86709d8ff7f95e7040e39f1c153903.tar.xz |
Update
Diffstat (limited to 'poky/documentation/migration-guides/migration-general.rst')
-rw-r--r-- | poky/documentation/migration-guides/migration-general.rst | 54 |
1 files changed, 54 insertions, 0 deletions
diff --git a/poky/documentation/migration-guides/migration-general.rst b/poky/documentation/migration-guides/migration-general.rst new file mode 100644 index 000000000..182482ec4 --- /dev/null +++ b/poky/documentation/migration-guides/migration-general.rst @@ -0,0 +1,54 @@ +General Migration Considerations +================================ + +Some considerations are not tied to a specific Yocto Project release. +This section presents information you should consider when migrating to +any new Yocto Project release. + +- *Dealing with Customized Recipes*: + + Issues could arise if you take + older recipes that contain customizations and simply copy them + forward expecting them to work after you migrate to new Yocto Project + metadata. For example, suppose you have a recipe in your layer that + is a customized version of a core recipe copied from the earlier + release, rather than through the use of an append file. When you + migrate to a newer version of Yocto Project, the metadata (e.g. + perhaps an include file used by the recipe) could have changed in a + way that would break the build. Say, for example, a function is + removed from an include file and the customized recipe tries to call + that function. + + You could "forward-port" all your customizations in your recipe so + that everything works for the new release. However, this is not the + optimal solution as you would have to repeat this process with each + new release if changes occur that give rise to problems. + + The better solution (where practical) is to use append files + (``*.bbappend``) to capture any customizations you want to make to a + recipe. Doing so, isolates your changes from the main recipe making + them much more manageable. However, sometimes it is not practical to + use an append file. A good example of this is when introducing a + newer or older version of a recipe in another layer. + +- *Updating Append Files*: + + Since append files generally only contain + your customizations, they often do not need to be adjusted for new + releases. However, if the ``.bbappend`` file is specific to a + particular version of the recipe (i.e. its name does not use the % + wildcard) and the version of the recipe to which it is appending has + changed, then you will at a minimum need to rename the append file to + match the name of the recipe file. A mismatch between an append file + and its corresponding recipe file (``.bb``) will trigger an error + during parsing. + + Depending on the type of customization the append file applies, other + incompatibilities might occur when you upgrade. For example, if your + append file applies a patch and the recipe to which it is appending + is updated to a newer version, the patch might no longer apply. If + this is the case and assuming the patch is still needed, you must + modify the patch file so that it does apply. + + + |