From 7fdd0ac087328524f27ae42d503898dbd113f417 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 28 Apr 2017 09:13:17 -0700 Subject: [PATCH] ref-manual: Applied 2.3 Migration review comments. (From yocto-docs rev: 08a077adea37d5b3eb3ac119b1a5981a6fef21a3) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/migration.xml | 169 ++++++++++++++++++------- 1 file changed, 120 insertions(+), 49 deletions(-) diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml index 5b6409d503..ddd6644240 100644 --- a/documentation/ref-manual/migration.xml +++ b/documentation/ref-manual/migration.xml @@ -3963,15 +3963,23 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. Yocto Project 2.3 Release from the prior release. -
- Sysroots +
+ Recipe-specific Sysroots The Open-Embedded build system now uses one sysroot per recipe to resolve long-standing issues with configuration script auto-detection of undeclared dependencies. - Consequently, you must explicitly declare all build-time - dependencies for your recipe. + Consequently, you might find that some of your previously + written custom recipes are missing declared dependencies, + particularly those dependencies that are incidentally built + earlier in a typical build process and thus are already likely + to be present in the shared sysroot in a previous release. + + + + Because of this new feature, you must explicitly declare all + build-time dependencies for your recipe. If you do not declare these dependencies, they are not populated into the sysroot for the recipe. @@ -3987,11 +3995,14 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. <filename>PATH</filename> Variable - The environment variable PATH is now - sanitized such that symbolic links linking only the binaries - from the host mentioned in the - HOSTTOOLS and - HOSTTOOLS_NONFATAL variables into + Within the environment used to run build tasks, the environment + variable PATH is now sanitized such that + symbolic links linking only the binaries from the host mentioned + in the + HOSTTOOLS + and + HOSTTOOLS_NONFATAL + variables into their own directory are added to PATH. Consequently, any native binaries that you need to call should either be in one of these two variables at the configuration @@ -3999,10 +4010,17 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. - Alternatively, you can use a native recipe (i.e. - -native) that includes the recipe's + Alternatively, you can add a native recipe (i.e. + -native) that provides the + binary to the recipe's DEPENDS value. + + PATH is not sanitized in the same way + within devshell. + If it were, you would have difficulty running host tools for + development and debugging within the shell. +
@@ -4023,29 +4041,6 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
-
- Dependency Tree Information - - - The package-depends.dot and - pn-depends.dot files as previously generated - using the bitbake -g command have been - removed. - A recipe-depends.dot file - is now generated as a collapsed version of - task-depends.dot instead. - - - - The reason for this change is because - package-depends.dot and - pn-depends.dot largely date back to a time - before task-based execution and do not take into account - task-level dependencies between recipes, which could be - misleading. - -
-
BitBake Changes @@ -4053,9 +4048,37 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. The following changes took place for BitBake: + BitBake's Graphical Dependency Explorer UI Replaced: BitBake's graphical dependency explorer UI depexp was replaced by - taskexp. + taskexp ("Task Explorer"), which + provides a graphical way of exploring the + task-depends.dot file. + The data presented by Task Explorer is much more + accurate than the data that is presented by + depexp. + Being able to visualize the data is an often requested + feature as standard *.dot file + viewers cannot usual cope with the size of + the task-depends.dot file. + + + Dependency Tree Information Removals: + The package-depends.dot and + pn-depends.dot files as previously + generated using the bitbake -g command + have been removed. + A recipe-depends.dot file + is now generated as a collapsed version of + task-depends.dot instead. + + + The reason for this change is because + package-depends.dot and + pn-depends.dot largely date back + to a time before task-based execution and do not take + into account task-level dependencies between recipes, + which could be misleading. @@ -4067,6 +4090,17 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. Absolute symbolic links (symlinks) within staged files are no longer permitted and now trigger an error. + Any explicit creation of symlinks can use the + lnr script, which is a replacement for + ln -r. + + + + If the build scripts in the software that the recipe is building + are creating a number of absolute symlinks that need to be + corrected, you can inherit + relative_symlinks within the recipe to turn + those absolute symlinks into relative symlinks.
@@ -4077,6 +4111,39 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. Older GPLv2 versions of GPLv3 recipes have moved to a separate meta-gplv2 layer. + + + If you use + INCOMPATIBLE_LICENSE + to exclude GPLv3 or set + PREFERRED_VERSION + to select recipes that use GPLv3, then you must add the + meta-gplv2 layer to your configuration. + + You can find meta-gplv2 layer in the + OpenEmbedded layer index at + . + + + + + These relocated GPLv3 recipes do not receive the same level of + maintenance as other core recipes. + The recipes do not get security fixes and upstream no longer + maintains them. + In fact, the upstream community is actively hostile towards people + that use the old versions of the recipes. + Moving these recipes into a separate layer both makes the different + needs of the recipes clearer and clearly identifies the number of + these recipes. + + The long-term solution might be to move to BSD-licensed + replacements of the GPLv3 components for those that need to + exclude GPLv3-licensed components from the target system. + This solution will be investigated for future Yocto + Project releases. + +
@@ -4109,30 +4176,30 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. it and maintaining the port is non-trivial. - Rpm 5.x itself is more or less unmaintained both - in the upstream and in Yocto Project. - Community support does not exist around it and - the Yocto Project is the sole remaining user. + Rpm 5.x itself has limited maintenance upstream, + and the Yocto Project is one of the very few + remaining users. - Berkeley db 6.x is removed and Berkeley db 5.x becomes + Berkeley DB 6.x is removed and Berkeley DB 5.x becomes the default: - Version 6.x of Berkeley DB has been rejected - by the open source community due to its hostile + Version 6.x of Berkeley DB has largely been + rejected by the open source community due to its AGPLv3 license. - Both Fedora and Debian are sticking - with db 5.x. + As a result, most mainstream open source projects + that require DB are still developed and tested with + DB 5.x. By extension,all the open source projects are still - developed and tested with db 5.x + developed and tested with DB 5.x In OE-core, the only thing that was requiring - db 6.x was Rpm 5.x. - Thus, no reason exists to continue carrying db 6.x + DB 6.x was Rpm 5.x. + Thus, no reason exists to continue carrying DB 6.x in OE-core. @@ -4162,11 +4229,15 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. Signing of remote package feeds using - PACKAGE_FEED_SIGN is not supported. + PACKAGE_FEED_SIGN + is not currently supported. + This issue will be fully addressed in a future + Yocto Project release. See the defect 11209 - for more information on a solution. + for more information on a solution to package feed + signing with RPM in the Yocto Project 2.3 release.