From 7f47526f5c99b09b5c3edc52290729e9303b3030 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Sun, 9 Apr 2017 12:27:11 -0700 Subject: ref-manual: Initial draft of 2.3 migration section. (From yocto-docs rev: c4c995aa94e5100e0d306eb91f490c23726ea91f) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/migration.xml | 212 +++++++++++++++++++++++++++++++++ 1 file changed, 212 insertions(+) (limited to 'documentation/ref-manual/migration.xml') diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml index 2bdb542ec1..92f8a7f67b 100644 --- a/documentation/ref-manual/migration.xml +++ b/documentation/ref-manual/migration.xml @@ -3955,6 +3955,218 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64. +
+ Moving to the Yocto Project 2.3 Release + + + This section provides migration information for moving to the + Yocto Project 2.3 Release from the prior release. + + +
+ 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 explicitely 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. + +
+ +
+ <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 + 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 + level. + + + + Alternatively, you can use a native recipe (i.e. + -native) that includes the recipe's + DEPENDS + value. + +
+ +
+ Changes to Functions + + + The previously deprecated + bb.data.getVar(), + bb.data.setVar(), and + related functions have been removed in favor of + d.getVar(), + d.setVar(), and so forth. + + + + You need to fix any references to these old functions. + +
+ +
+ 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 + + + The following changes took place for BitBake: + + + BitBake's graphical dependency explorer UI + depexp was replaced by + taskexp. + + + +
+ + + +
+ GPLv2 Versions of GPLv3 Recipes Moved + + + Older GPLv2 versions of GPLv3 recipes have moved to a + separate meta-gplv2 layer. + +
+ +
+ Package Management Changes + + + The following package management changes took place: + + + Smart package manager is replaced by Dnf package manager. + Smart has become unmaintained upstream, is not ported + to Python 3.x. + Consequently, Smart needed to be replaced. + Dnf is the only feasible candidate. + The change in functionality is that the on-target + runtime package management from remote package feeds is + now done with a different tool that has a + different set of command-line options. + If you have scripts that call the + tool directly, or use its API, they need to be fixed. + For more information, see the + Dnf Documentation. + + + Rpm 5.x is replaced with Rpm 4.x. + This is done for two major reasons: + + + Dnf is API-incompatible with Rpm 5.x and porting + 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. + + + + + 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 + AGPLv3 license. + Both Fedora and Debian are sticking + with db 5.x. + By extension,all the open source projects are still + 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 + in OE-core. + + + + + createrepo is replaced with + createrepo_c. + createrepo_c is the current + incarnation of the tool that generates remote repository + metadata. + It is written in C as compared to + createrepo, which is written in + Python. + createrepo_c is faster and is + maintained. + + + Architecture-independent RPM packages are "noarch" + instead of "all". + This change was made because too many places in + dnf/rpm4 stack already make that assumption. + Only the filenames and the architecture tag has changed. + Nothing else has changed in OE-core system, particularly + in the + allarch.bbclass + class. + + + Signing of remote package feeds using + PACKAGE_FEED_SIGN is not supported. + + See the defect + 11209 + for more information on a solution. + + + + +
+