From: Scott Rifenbark Date: Thu, 11 Jan 2018 19:02:11 +0000 (-0800) Subject: overview-manual, ref-manual: Moved auto added runtime deps section X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a60d9e29171eaf73dc5ce70fdd2ce92ec07876ec;p=thirdparty%2Fopenembedded%2Fopenembedded-core-contrib.git overview-manual, ref-manual: Moved auto added runtime deps section Fixes [YOCTO #12370] The "Automatically Added Runtime Dependencies" section moved from the ref-manual to the overview-manual. This topic is concepts and needs to live in the new overview-manual's concepts chapter. Fixed some links in the ref-manual and one in the dev-manual. (From yocto-docs rev: fa3e12030ce867cb81feed453d35c3a3643decd2) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 8a0d6a32225..b1414987630 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -2275,8 +2275,8 @@ automatically add a runtime dependency to "mypackage" on "example"). See the - "Automatically Added Runtime Dependencies" - in the Yocto Project Reference Manual for further details. + "Automatically Added Runtime Dependencies" + in the Yocto Project Overview Manual for further details. @@ -3417,8 +3417,8 @@ allows runtime dependencies between packages to be added automatically. See the - "Automatically Added Runtime Dependencies" - section in the Yocto Project Reference Manual + "Automatically Added Runtime Dependencies" + section in the Yocto Project Overview Manual for more information. diff --git a/documentation/overview-manual/overview-concepts.xml b/documentation/overview-manual/overview-concepts.xml index 2d704923faf..9fb3283feea 100644 --- a/documentation/overview-manual/overview-concepts.xml +++ b/documentation/overview-manual/overview-concepts.xml @@ -1106,6 +1106,153 @@ +
+ Automatically Added Runtime Dependencies + + + The OpenEmbedded build system automatically adds common types of + runtime dependencies between packages, which means that you do not + need to explicitly declare the packages using + RDEPENDS. + Three automatic mechanisms exist (shlibdeps, + pcdeps, and depchains) + that handle shared libraries, package configuration (pkg-config) + modules, and -dev and + -dbg packages, respectively. + For other types of runtime dependencies, you must manually declare + the dependencies. + + + shlibdeps: + During the + do_package + task of each recipe, all shared libraries installed by the + recipe are located. + For each shared library, the package that contains the + shared library is registered as providing the shared + library. + More specifically, the package is registered as providing + the + soname + of the library. + The resulting shared-library-to-package mapping + is saved globally in + PKGDATA_DIR + by the + do_packagedata + task. + + Simultaneously, all executables and shared libraries + installed by the recipe are inspected to see what shared + libraries they link against. + For each shared library dependency that is found, + PKGDATA_DIR is queried to + see if some package (likely from a different recipe) + contains the shared library. + If such a package is found, a runtime dependency is added + from the package that depends on the shared library to the + package that contains the library. + + The automatically added runtime dependency also + includes a version restriction. + This version restriction specifies that at least the + current version of the package that provides the shared + library must be used, as if + "package (>= version)" + had been added to + RDEPENDS. + This forces an upgrade of the package containing the shared + library when installing the package that depends on the + library, if needed. + + If you want to avoid a package being registered as + providing a particular shared library (e.g. because the library + is for internal use only), then add the library to + PRIVATE_LIBS + inside the package's recipe. + + + pcdeps: + During the + do_package + task of each recipe, all pkg-config modules + (*.pc files) installed by the recipe + are located. + For each module, the package that contains the module is + registered as providing the module. + The resulting module-to-package mapping is saved globally in + PKGDATA_DIR + by the + do_packagedata + task. + + Simultaneously, all pkg-config modules installed by + the recipe are inspected to see what other pkg-config + modules they depend on. + A module is seen as depending on another module if it + contains a "Requires:" line that specifies the other module. + For each module dependency, + PKGDATA_DIR is queried to see if some + package contains the module. + If such a package is found, a runtime dependency is added + from the package that depends on the module to the package + that contains the module. + + The pcdeps mechanism most often + infers dependencies between -dev + packages. + + + + depchains: + If a package foo depends on a package + bar, then foo-dev + and foo-dbg are also made to depend on + bar-dev and + bar-dbg, respectively. + Taking the -dev packages as an + example, the bar-dev package might + provide headers and shared library symlinks needed by + foo-dev, which shows the need + for a dependency between the packages. + + The dependencies added by + depchains are in the form of + RRECOMMENDS. + + By default, foo-dev also has an + RDEPENDS-style dependency on + foo, because the default value of + RDEPENDS_${PN}-dev (set in + bitbake.conf) includes + "${PN}". + + + To ensure that the dependency chain is never broken, + -dev and -dbg + packages are always generated by default, even if the + packages turn out to be empty. + See the + ALLOW_EMPTY + variable for more information. + + + + + + The do_package task depends on the + do_packagedata + task of each recipe in + DEPENDS + through use of a + [deptask] + declaration, which guarantees that the required + shared-library/module-to-package mapping information will be available + when needed as long as DEPENDS has been + correctly set. + +
+
x32 psABI diff --git a/documentation/ref-manual/ref-tasks.xml b/documentation/ref-manual/ref-tasks.xml index a90f02b7d82..09095958340 100644 --- a/documentation/ref-manual/ref-tasks.xml +++ b/documentation/ref-manual/ref-tasks.xml @@ -342,8 +342,8 @@ For additional information, see the PKGDESTWORK variable and the - "Automatically Added Runtime Dependencies" - section. + "Automatically Added Runtime Dependencies" + section in the Yocto Project Overview Manual.
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml index 564bb38ac67..67cf8859ee1 100644 --- a/documentation/ref-manual/ref-variables.xml +++ b/documentation/ref-manual/ref-variables.xml @@ -3263,8 +3263,9 @@ add any runtime dependencies between the packages produced by the two recipes. However, as explained in the - "Automatically Added Runtime Dependencies" - section, runtime dependencies will often be + "Automatically Added Runtime Dependencies" + section in the Yocto Project Overview Manual, + runtime dependencies will often be added automatically, meaning DEPENDS alone is sufficient for most recipes. @@ -10407,10 +10408,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" ${STAGING_DIR_HOST}/pkgdata For examples of how this data is used, see the - "Automatically Added Runtime Dependencies" - section and the + "Automatically Added Runtime Dependencies" + section in the Yocto Project Overview Manual and the "Viewing Package Information with oe-pkgdata-util" - section. + section elsewhere in this manual. @@ -10914,8 +10915,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" For more information, see the - "Automatically Added Runtime Dependencies" - section. + "Automatically Added Runtime Dependencies" + section in the Yocto Project Overview Manual. @@ -11231,8 +11232,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Therefore, most recipes do not need to set RDEPENDS. For more information, see the - "Automatically Added Runtime Dependencies" - section. + "Automatically Added Runtime Dependencies" + section in the Yocto Project Overview Manual. diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 06a018b8a99..b30dfe8597a 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml @@ -13,150 +13,6 @@ x32, Wayland support, and Licenses. -
- Automatically Added Runtime Dependencies - - - The OpenEmbedded build system automatically adds common types of - runtime dependencies between packages, which means that you do not - need to explicitly declare the packages using - RDEPENDS. - Three automatic mechanisms exist (shlibdeps, - pcdeps, and depchains) that - handle shared libraries, package configuration (pkg-config) modules, - and -dev and -dbg packages, - respectively. - For other types of runtime dependencies, you must manually declare - the dependencies. - - - shlibdeps: - During the - do_package - task of each recipe, all shared libraries installed by the - recipe are located. - For each shared library, the package that contains the shared - library is registered as providing the shared library. - More specifically, the package is registered as providing the - soname - of the library. - The resulting shared-library-to-package mapping - is saved globally in - PKGDATA_DIR - by the - do_packagedata - task. - - Simultaneously, all executables and shared libraries - installed by the recipe are inspected to see what shared - libraries they link against. - For each shared library dependency that is found, - PKGDATA_DIR is queried to - see if some package (likely from a different recipe) contains - the shared library. - If such a package is found, a runtime dependency is added from - the package that depends on the shared library to the package - that contains the library. - - The automatically added runtime dependency also includes - a version restriction. - This version restriction specifies that at least the current - version of the package that provides the shared library must be - used, as if - "package (>= version)" - had been added to - RDEPENDS. - This forces an upgrade of the package containing the shared - library when installing the package that depends on the - library, if needed. - - If you want to avoid a package being registered as - providing a particular shared library (e.g. because the library - is for internal use only), then add the library to - PRIVATE_LIBS - inside the package's recipe. - - - pcdeps: - During the - do_package - task of each recipe, all pkg-config modules - (*.pc files) installed by the recipe are - located. - For each module, the package that contains the module is - registered as providing the module. - The resulting module-to-package mapping is saved globally in - PKGDATA_DIR - by the - do_packagedata - task. - - Simultaneously, all pkg-config modules installed by the - recipe are inspected to see what other pkg-config modules they - depend on. - A module is seen as depending on another module if it contains - a "Requires:" line that specifies the other module. - For each module dependency, - PKGDATA_DIR is queried to see if some - package contains the module. - If such a package is found, a runtime dependency is added from - the package that depends on the module to the package that - contains the module. - - The pcdeps mechanism most often infers - dependencies between -dev packages. - - - - depchains: - If a package foo depends on a package - bar, then foo-dev - and foo-dbg are also made to depend on - bar-dev and bar-dbg, - respectively. - Taking the -dev packages as an example, - the bar-dev package might provide - headers and shared library symlinks needed by - foo-dev, which shows the need - for a dependency between the packages. - - The dependencies added by depchains - are in the form of - RRECOMMENDS. - - By default, foo-dev also has an - RDEPENDS-style dependency on - foo, because the default value of - RDEPENDS_${PN}-dev (set in - bitbake.conf) includes - "${PN}". - - - To ensure that the dependency chain is never broken, - -dev and -dbg - packages are always generated by default, even if the packages - turn out to be empty. - See the - ALLOW_EMPTY - variable for more information. - - - - - - The do_package task depends on the - do_packagedata - task of each recipe in - DEPENDS - through use of a - [deptask] - declaration, which guarantees that the required - shared-library/module-to-package mapping information will be available - when needed as long as DEPENDS has been - correctly set. - -
-
Fakeroot and Pseudo