From a60d9e29171eaf73dc5ce70fdd2ce92ec07876ec Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 11 Jan 2018 11:02:11 -0800 Subject: 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 --- documentation/ref-manual/technical-details.xml | 144 ------------------------- 1 file changed, 144 deletions(-) (limited to 'documentation/ref-manual/technical-details.xml') diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 06a018b8a9..b30dfe8597 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 -- cgit v1.2.3-54-g00ecf