summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorKoen Kooi <koen@openembedded.org>2006-08-26 17:25:27 +0000
committerKoen Kooi <koen@openembedded.org>2006-08-26 17:25:27 +0000
commit503afeb90739399a6d315d5083614861d5033930 (patch)
tree820e807ead579e78ca2fb9786ba10cdf456b61ce
parentcc4364acf06857a82842917172b8e0ac3a1a5a66 (diff)
downloadopenembedded-503afeb90739399a6d315d5083614861d5033930.tar.gz
docs/packaged-staging.xml: clear up concerns about p-s + bitbake-mt
-rw-r--r--docs/packaged-staging.xml2
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/packaged-staging.xml b/docs/packaged-staging.xml
index 1b5919e47a..f0713a996b 100644
--- a/docs/packaged-staging.xml
+++ b/docs/packaged-staging.xml
@@ -54,7 +54,7 @@ And some terminology:
</section>
<section>
- <title>Incrementally installing packages</title> <para>In contrast to repopluating the staging area from scratch we install additional dependencies and remove conflicting packages. The installing and removing of packages is assumed to be faster than repopulating from scratch. Once a package completed we could consider removing the non-native depends to avoid a growing staging directory. One issue is with the clean task. We could assume that cleaning a package will remove it from the staging area as well. There is one possible problem with it. Let us assume we want to clean quilt-native, virtually every package DEPENDS on it, we would have to clean the staging area completely. If this is the wished behaviour needs to be discussed. This should be safe for a multithreaded bitbake, given that no two do_stages access staging at the same time.
+ <title>Incrementally installing packages</title> <para>In contrast to repopluating the staging area from scratch we install additional dependencies and remove conflicting packages. The installing and removing of packages is assumed to be faster than repopulating from scratch. Once a package completed we could consider removing the non-native depends to avoid a growing staging directory. One issue is with the clean task. We could assume that cleaning a package will remove it from the staging area as well. There is one possible problem with it. Let us assume we want to clean quilt-native, virtually every package DEPENDS on it, we would have to clean the staging area completely. If this is the wished behaviour needs to be discussed. This should be safe for a multithreaded bitbake, given that do_stages is the only task running, all other task will have to wait for staging to be complete.
</para>
</section>
</chapter>