mirrors/buildroot
0
0
Fork 0
mirror of https://git.busybox.net/buildroot.git synced 2024-11-23 05:23:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs/manual: rephrase end of vendoring section

Browse Source 
The current phrasing is not entirely clear: one could read it as if
Buildroot will detect if there's an update available in one of the
dependencies, which is quite the reverse of what we do. Rephrase the
sentence in a way that hopefully makes it clearer that we're just making
a hash of the dependencies.

While we're at it, also extend the sentence about offline builds a
little.

Suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This commit is contained in:
Arnout Vandecappelle 2024-07-14 10:50:01 +02:00
parent 19c76b190d
commit 804edd8683
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/manual/adding-packages-cargo.adoc
View File

@ -93,7 +93,9 @@ takes care of downloading such dependencies as part of the download
step of packages that use the +cargo-package+ infrastructure. Such
dependencies are then kept together with the package source code in
the tarball cached in Buildroot's +DL_DIR+, and therefore the hash of
the package's tarball includes such dependencies.
This mechanism ensures that any change in the dependencies will be
detected, and allows the build to be performed completely offline.
the package's tarball doesn't only cover the source of the package
itself, but also covers the sources of the dependencies. Thus, a change
injected into one of the dependencies will also be discovered by the
hash check. In addition, this mechanism allows the build to be
performed completely offline since cargo will not do any downloads
during the build. This mechanism is called vendoring the dependencies.