[bitbake-devel] [PATCH] bitbake/usermanual: Update to be more in sync with bitbake codebase

[Mark Hatle]

Found a typo...

On 8/10/11 10:12 AM, Richard Purdie wrote:
> Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
> ---
> diff --git a/bitbake/doc/manual/usermanual.xml b/bitbake/doc/manual/usermanual.xml
> index 7dea949..01b69b8 100644
> --- a/bitbake/doc/manual/usermanual.xml
> +++ b/bitbake/doc/manual/usermanual.xml

...

> @@ -53,10 +54,18 @@ between multiple projects using BitBake for their
>  builds.</para></listitem>
>  		<listitem><para>Should provide an inheritance mechanism to
>  share common metadata between many packages.</para></listitem>
> -                <listitem><para>Et cetera...</para></listitem>
>              </itemizedlist>
>          </para>
> -        <para>BitBake satisfies all these and many more.  Flexibility and power have always been the priorities.  It is highly extensible, supporting embedded Python code and execution of any arbitrary tasks.</para>
> +        <para>Over time it has become apparent that some further requirements were necessary:
> +            <itemizedlist>
> +                <listitem><para>Handle variants of a base recipe (native, sdk, mutliblib).</para></listitem>

"multilib"  ;)

> +                <listitem><para>Able to split metadata into layers and allow layers to override each other.</para></listitem>
> +                <listitem><para>Allow representation of a given set of input variables to a task as a checksum.</para></listitem>
> +                <listitem><para>based on that checksum, allow acceleration of builds with prebuilt components.</para></listitem>
> +            </itemizedlist>
> +        </para>
> +
> +        <para>BitBake satisfies all the original requirements and many more with extensions being made to the basic functionality to reflect the additionl requirements.  Flexibility and power have always been the priorities.  It is highly extensible, supporting embedded Python code and execution of any arbitrary tasks.</para>
>          </section>
>      </chapter>
>      <chapter>

> @@ -299,13 +366,35 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
>          <title>File download support</title>
>          <section>
>              <title>Overview</title>
> -            <para>BitBake provides support to download files this procedure is called fetching. The SRC_URI is normally used to tell BitBake which files to fetch. The next sections will describe the available fetchers and their options. Each fetcher honors a set of variables and per URI parameters separated by a <quote>;</quote> consisting of a key and a value. The semantics of the variables and parameters are defined by the fetcher. BitBake tries to have consistent semantics between the different fetchers.
> +            <para>BitBake provides support to download files this procedure is called fetching and it handled by the fetch and fetch2 modules. At this point the original fetch code is considered to be replaced by fetch2 and this manual only related to the fetch2 codebase.</para>
> +
> +            <para>The SRC_URI is normally used to tell BitBake which files to fetch. The next sections will describe the available fetchers and their options. Each fetcher honors a set of variables and per URI parameters separated by a <quote>;</quote> consisting of a key and a value. The semantics of the variables and parameters are defined by the fetcher. BitBake tries to have consistent semantics between the different fetchers.
>              </para>
> +
> +            <para>The overall fetch process is that first, fetches are attempted from PREMIRRORS. If those don't work, the original SRC_URI is attempted and if that fails, bitbake will fall back to MIRRORS. Cross urls are supported, so its possible to mirror a git repostory on an http server as a tarball for example. Some example commonly used mirror defintions are:</para>

Should it be "BitBake" instead of bitbake?

"repository" and "definitions"

...