diff options
author | Koen Kooi <koen@openembedded.org> | 2006-08-26 17:25:27 +0000 |
---|---|---|
committer | Koen Kooi <koen@openembedded.org> | 2006-08-26 17:25:27 +0000 |
commit | 503afeb90739399a6d315d5083614861d5033930 (patch) | |
tree | 820e807ead579e78ca2fb9786ba10cdf456b61ce | |
parent | cc4364acf06857a82842917172b8e0ac3a1a5a66 (diff) | |
download | openembedded-503afeb90739399a6d315d5083614861d5033930.tar.gz |
docs/packaged-staging.xml: clear up concerns about p-s + bitbake-mt
-rw-r--r-- | docs/packaged-staging.xml | 2 |
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> |