docs: import usermanual from org.openembedded.documentation.

org.openembedded.documentation is deprecated now; please do all updates here!

16 files changed, 3747 insertions, 0 deletions

diff --git a/docs/usermanual/reference/.mtn2git_empty b/docs/usermanual/reference/.mtn2git_empty
new file mode 100644
index 0000000000..e69de29bb2
--- /dev/null
+++ b/docs/usermanual/reference/.mtn2git_empty
diff --git a/docs/usermanual/reference/class_autotools.xml b/docs/usermanual/reference/class_autotools.xml
new file mode 100644
index 0000000000..a9e1a5721a
--- /dev/null
+++ b/docs/usermanual/reference/class_autotools.xml
@@ -0,0 +1,153 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section id="autotools_class" xreflabel="autotools class">
+  <title>autotools class</title>
+
+  <para>Autotools is one of the most commonly seen configuration methods for
+  applications. Anything that uses the standard <command>./configure; make;
+  make install</command> sequence is using autotools. Usually the configure
+  script will support a large number of options to specify various
+  installation directories, to disable and/or enable various features and
+  options to specify search paths for headers and libraries.</para>
+
+  <para>The autotools class takes care of all of the details for you. It
+  defines appropriate tasks for <emphasis>configure</emphasis>,
+  <emphasis>compile</emphasis>, <emphasis>stage</emphasis> and
+  <emphasis>install</emphasis>. At it's simplest adding an inherit for the
+  autotools class is all that is required. The netcat recipe for example
+  is:<screen>DESCRIPTION = "GNU Netcat"
+HOMEPAGE = "http://netcat.sourceforge.net"
+LICENSE = "GPLv2"
+MAINTAINER = "Your name &lt;yname@example.com&gt;"
+SECTION = "console/networking"
+PR = "r1"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/netcat/netcat-${PV}.tar.bz2"
+
+inherit autotools</screen>The header is defined, the location of the source
+  code and then the inherit. For the simplest cases this is all that is
+  required. If you need to pass additional parameters to the configure script,
+  such as for enabling and/or disabling options, then they can be specified
+  via the <command>EXTRA_OECONF</command> variable. This example from the lftp
+  recipe shows several extra options being passed to the configure
+  script:<screen>EXTRA_OECONF = "--disable-largefile --disable-rpath --with-included-readline=no"</screen>If
+  you define your own tasks for <emphasis>configure</emphasis>,
+  <emphasis>compile</emphasis>, <emphasis>stage</emphasis> or
+  <emphasis>install</emphasis> (via <command>do_&lt;taskname&gt;</command>)
+  then they will override the methods generated by the autotools class. If you
+  need to perform additional operations (rather than replacing the generated
+  operations) you can use the <command>do_&lt;task&gt;_append</command> or
+  <command>do_&lt;task&gt;_prepend</command> methods. The following example
+  from the conserver recipe shows some additional items being
+  installed:<screen># Include the init script and default settings in the package
+do_install_append () {
+    install -m 0755 -d ${D}${sysconfdir}/default ${D}${sysconfdir}/init.d
+    install -m 0644 ${WORKDIR}/conserver.default ${D}${sysconfdir}/default/conserver
+    install -m 0755 ${WORKDIR}/conserver.init ${D}${sysconfdir}/init.d/conserver
+}</screen></para>
+
+  <section>
+    <title>oe_runconf / autotools_do_configure</title>
+
+    <para>Autotools generates a configuration method called
+    <command>oe_runconf</command> which runs the actual configure script, and
+    a method called <command>autotools_do_configure</command> which generates
+    the configure file (runs automake and autoconf) and then calls
+    <command>oe_runconf</command>. The generated method for the
+    <emphasis>configure</emphasis> task, <command>do_configure</command>, just
+    calls the <command>autotools_do_configure</command> method.</para>
+
+    <para>It is sometimes desirable to implement your own
+    <command>do_configure</command> method, where additional configuration is
+    required or where you wish to inhibit the running of automake and
+    autoconf, and then manually call <command>oe_runconf</command>.</para>
+
+    <para>The following example from the ipacct recipe shows an example of
+    avoiding the use of automake/autoconf:<screen>do_configure() {
+    oe_runconf
+}</screen>Sometimes manual manipulations of the autotools files is required
+    prior to calling autoconf/automake. In this case you can defined your own
+    <command>do_configure</command> method which performs the required actions
+    and then calls <command>autotools_do_configure</command>.</para>
+  </section>
+
+  <section>
+    <title>Presetting autoconf variables (the site file)</title>
+
+    <para>The autotools configuration method has support for caching the
+    results of tests. In the cross-compilation case it is sometimes necessary
+    to prime the cache with per-calculated results (since tests designed to
+    run on the target cannot be run when cross-compiling). These are defined
+    via the site file(s) for the architecture you are using and may be
+    specific to the package you are building.</para>
+
+    <para>Autoconf uses site files as definied in the
+    <command>CONFIG_SITE</command> variable, which is a space seperate list of
+    files to load in the specified order. Details on how this variable is set
+    is provided in the <xref linkend="siteinfo_class" /> (the class
+    responsbile for setting the variable) section.</para>
+
+    <para>There are some things that you should keep in mind about the caching
+    of configure tests:</para>
+
+    <orderedlist>
+      <listitem>
+        <para>Check the other site files to see if there any entries for the
+        application you are attempting to build.</para>
+
+        <para>Sometimes entries are only updated for the target that the
+        developer has access to. If they exist for another target then it may
+        provide a good idea of what needs to be defined.</para>
+      </listitem>
+
+      <listitem>
+        <para>Sometimes the same cache value is used by multiple
+        applications.</para>
+
+        <para>This can have the side effect where a value added for one
+        application breaks the build of another. It is a very good idea to
+        empty the site file of all other values if you are having build
+        problems to ensure that none of the existing values are causing
+        problems.</para>
+      </listitem>
+
+      <listitem>
+        <para>Not all values can be stored in the cache</para>
+
+        <para>Caching of variables is defined by the author of the configure
+        script, so sometimes not all variables can be set via the cache. In
+        this case it often means resorting to patching the original configure
+        scripts to achieve the desired result.</para>
+      </listitem>
+    </orderedlist>
+
+    <para>All site files are shell scripts which are run by autoconf and
+    therefore the syntax is the same as you would use in sh. There are two
+    current methods of settings variables that is used in the existing site
+    files. This include explicitly settings the value of the variable:<screen>ac_cv_sys_restartable_syscalls=yes</screen>and
+    conditionally setting the value of the variable:<screen>ac_cv_uchar=${ac_cv_uchar=no}</screen>The
+    conditional version is using shell syntax to say "<emphasis>only set this
+    to the specified value if it is not currently set</emphasis>". The
+    conditional version allows the variable to be set in the shell prior to
+    calling configure and it will then not be replaced by the value from the
+    site file.</para>
+
+    <note>
+      <para>Site files are applied in order, so the application specific site
+      files will be applied prior to the top level site file entries. The use
+      of conditional assignment means that the first definition found will
+      apply, while when not using conditionals the last definition found will
+      apply.</para>
+    </note>
+
+    <para>It is possible to disable the use of the cached values from the site
+    file by clearing the definition of <command>CONFIG_SITE</command> prior to
+    running the configure script. Doing this will disable the use of the site
+    file entirely. This however should be used as a last resort. The following
+    example from the db recipe shows an example of this:<screen># Cancel the site stuff - it's set for db3 and destroys the
+# configure.
+CONFIG_SITE = ""
+do_configure() {
+    oe_runconf
+}</screen></para>
+  </section>
+</section>
\ No newline at end of file
diff --git a/docs/usermanual/reference/class_binconfig.xml b/docs/usermanual/reference/class_binconfig.xml
new file mode 100644
index 0000000000..049f85e1f0
--- /dev/null
+++ b/docs/usermanual/reference/class_binconfig.xml
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section id="binconfig_class" xreflabel="binconfig class">
+  <title>binconfig class</title>
+
+  <para>The binconfig class is for packages that install
+  <command>&lt;pkg&gt;-config</command> scripts that provide information about
+  the build settings for the package. It is usually provided by libraries and
+  then used by other packages to determine various compiler options.</para>
+
+  <para>Since the script is used at build time it is required to be copied
+  into the staging area. All the actions performed by the class are appended
+  to the <emphasis>stage</emphasis> task.</para>
+
+  <para>The actions performed by the binconfig class are:</para>
+
+  <orderedlist>
+    <listitem>
+      <para>Copies the <command>&lt;x&gt;-config</command> script from the
+      package into <command>${STAGING_BINDIR} </command>directory;</para>
+    </listitem>
+
+    <listitem>
+      <para>If the package is not native then it modifies the contents of the
+      <command>&lt;x&gt;-config</command> script in the staging area to ensure
+      that all the paths in the script refer to the staging area;</para>
+    </listitem>
+
+    <listitem>
+      <para>If the package is native then
+      the<command>&lt;x&gt;-config</command> script is renamed to
+      <command>&lt;x&gt;-config-native</command> to ensure that the native and
+      non-native versions do not interfere with each other.</para>
+    </listitem>
+  </orderedlist>
+
+  <para>A package is considered to be native if it also inherits the native
+  class.</para>
+
+  <para>The class will search in source directory, <command>${S}</command>,
+  and all it's subdirectories, for files that end in
+  <command>-config</command> and process them as described above. All that is
+  required to use the class is the addition of binconfig in an inherit
+  statement:</para>
+
+  <para><screen>inherit autotools binconfig</screen></para>
+</section>
\ No newline at end of file
diff --git a/docs/usermanual/reference/class_distutils.xml b/docs/usermanual/reference/class_distutils.xml
new file mode 100644
index 0000000000..ddc9c721ab
--- /dev/null
+++ b/docs/usermanual/reference/class_distutils.xml
@@ -0,0 +1,48 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section id="distutils_class" xreflabel="distutils class">
+  <title>distutils class</title>
+
+  <para>Distutils is a standard python system for building and installing
+  modules. The <emphasis>distutils</emphasis> class is used to automate the
+  building of python modules that use the distutils system.</para>
+
+  <para>Any python package that requires the standard python commands to build
+  and install is using the distutils system and should be able to use this
+  class:<screen>python setup.py build
+python setup.py install</screen></para>
+
+  <para>The <emphasis>distutils</emphasis> class will perform the build and
+  install actions on the <command>setup.py</command> provided by the package,
+  as required for building distutils packages, including setting all the
+  required parameters for cross compiling. It willl also perform the following
+  actions:</para>
+
+  <orderedlist>
+    <listitem>
+      <para>Adds python-native to <command>DEPENDS</command> to ensure that
+      python is built and installed on the build host. This also ensure that
+      the version of python that is used during package creation matches the
+      version of python that will be installed on the target.</para>
+    </listitem>
+
+    <listitem>
+      <para>Adds python-core to <command>RDEPENDS</command> to ensure that the
+      python-core is installed when this module is installed. Note that you
+      need to manually add any other python module dependencies to
+      <command>RDEPENDS</command>.</para>
+    </listitem>
+  </orderedlist>
+
+  <para>The following example from the <emphasis>moin</emphasis> recipe shows
+  how simple this can make a python package:<screen>DESCRIPTION = "A full fledged WikiWiki system written in Python"
+LICENSE = "GPL"
+SECTION = "base"
+PRIORITY = "optional"
+MAINTAINER = "Your name &lt;yname@example.com&gt;"
+PR = "r1"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/moin/moin-${PV}.tar.gz"
+
+inherit distutils</screen>The header, source location and the inherit are all
+  that is required.</para>
+</section>
\ No newline at end of file
diff --git a/docs/usermanual/reference/class_image.xml b/docs/usermanual/reference/class_image.xml
new file mode 100644
index 0000000000..b591e9aae2
--- /dev/null
+++ b/docs/usermanual/reference/class_image.xml
@@ -0,0 +1,358 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section id="image_class" xreflabel="image class">
+  <title>image class</title>
+
+  <para>The image class is used to generate filesystem images containing a
+  root filesystem, as generated by the rootfs class for the package type, such
+  as <xref linkend="rootfs_ipkg_class" />, for use on the target device. This
+  could be a <emphasis>jffs2</emphasis> image which is to be written directly
+  into the flash on the target device for example. In addition this class also
+  configures the ipkg feeds (where to get updates from) and is able to
+  generate multiple different image types.</para>
+
+  <para>Summary of the actions performed by the
+  <emphasis>image_ipkg</emphasis> class:</para>
+
+  <orderedlist>
+    <listitem>
+      <para>Inherits the rootfs class for the appropriate package type,
+      typically <xref linkend="rootfs_ipkg_class" />, in order to bring in the
+      functionality required to generate a root filesystem image. The root
+      filesystem image is generate from a set of of packages (typically .ipkg
+      packages), and then the required images are generated using the contents
+      of the root filesystem;</para>
+    </listitem>
+
+    <listitem>
+      <para>Sets <command>BUILD_ALL_DEPS = "1"</command> to force the
+      dependency system to build all packages that are listed in the
+      <command>RDEPENDS</command> and/or <command>RRECOMENDS</command> of the
+      packages to be installed;</para>
+    </listitem>
+
+    <listitem>
+      <para>Determines the name of the image device tables or table
+      (<command>IMAGE_DEVICE_TABLES/IMAGE_DEVICE_TABLE</command>) which will
+      be used to describe the device nodes to create in
+      <command>/dev</command> directory in the root filesystem;</para>
+    </listitem>
+
+    <listitem>
+      <para>Erases the contents of any existing root filesystem image,
+      <command>${IMAGE_ROOTFS}</command>;</para>
+    </listitem>
+
+    <listitem>
+      <para>If devfs is not being used then the <command>/dev</command>
+      directory, <command>${IMAGE_ROOTFS}/dev</command>, will be created and
+      then populated with the device nodes described by the image device table
+      or tables (using "<command>makedevs -r ${IMAGE_ROOTFS} -D
+      &lt;table&gt;</command>" for each device table);</para>
+    </listitem>
+
+    <listitem>
+      <para>Calls into <xref linkend="rootfs_ipkg_class" /> to install all of
+      the required packages into the root filesystem;</para>
+    </listitem>
+
+    <listitem>
+      <para>Configures the ipkg feed information in the root filesystem 
+      (using <command>FEED_URIS</command> and <command>FEED_DEPLOYDIR_BASE_URI</command>);</para>
+    </listitem>
+
+    <listitem>
+      <para>Runs any image pre-processing commands as specified via
+      <command>${IMAGE_PREPROCESS_COMMAND}</command>;</para>
+    </listitem>
+
+    <listitem>
+      <para>Calls <command>bbimage</command> on the root filesystem for each
+      required image type, as specified via
+      <command>${IMAGE_FSTYPES}</command>, to generate the actual filesystem
+      images;</para>
+    </listitem>
+
+    <listitem>
+      <para>Runs any image post-processing commands, as specified via
+      <command>${IMAGE_POSTPROCESS_COMMAND}</command>.</para>
+    </listitem>
+  </orderedlist>
+
+  <para>The following variables may be used to control some of the behaviour
+  of this class (remember we use <xref linkend="rootfs_ipkg_class" /> to build
+  the filesystem image, so look at the variables defined by that class as
+  well):</para>
+
+  <variablelist>
+    <varlistentry>
+      <term>USE_DEVFS</term>
+
+      <listitem>
+        <para>Indicates if the image will be using devfs, the device
+        filesystem, or not. If devfs is being used then no
+        <command>/dev</command> directory will be required in the image. Set
+        to <command>"1"</command> to indicate that devfs is being used. Note
+        that devfs has been removed from the Linux kernel in the 2.6 series
+        and most platforms are moving towards the use of udev as a replacement
+        for devfs.</para>
+
+        <para>Default: <command>"0"</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>IMAGE_DEVICE_TABLES</term>
+
+      <listitem>
+        <para>Specifies one, or more, files containing a list of the device
+        nodes that should be created in the <command>/dev</command> directory
+        of the image. Each file is searched for via the
+        <command>${BBPATH}</command> and therefore can be specified as a file
+        relative to the top of the build. Device files are processed in the
+        specified order. NOTE: If <command>IMAGE_DEVICE_TABLE</command> is set
+        then this variable is ignored.</para>
+
+        <para>Example: <command>IMAGE_DEVICE_TABLES =
+        "files/device_table-minimal.txt files/device_table_add-sci.txt
+        device_table_add-sm.txt"</command></para>
+
+        <para>Default:
+        <command>"files/device_table-minimal.txt"</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>IMAGE_DEVICE_TABLE</term>
+
+      <listitem>
+        <para>Specifies the file that lists the device nodes that should be
+        created in the <command>/dev </command>directory of the image. This
+        needs to be an absolute filename and so should be specified relative
+        to <command>${BBPATH}</command>. Only a single device table is
+        supported. Use <command>IMAGE_DEVICE_TABLES</command> instead if you
+        want to use multiple device tables.</para>
+
+        <para>Default: <command>""</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>IMAGE_PREPROCESS_COMMAND</term>
+
+      <listitem>
+        <para>Additional commands to run prior to processing the image. Note
+        that these command run within the same <xref linkend="fakeroot" />
+        instance as the rest of this class.</para>
+
+        <para>Default: <command>""</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>IMAGE_POSTPROCESS_COMMAND</term>
+
+      <listitem>
+        <para>Additional commands to run after processing the image. Note that
+        these command run within the same <xref linkend="fakeroot" /> instance
+        as the rest of this class.</para>
+
+        <para>Default: <command>""</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>IMAGE_FSTYPES</term>
+
+      <listitem>
+        <para>Specifies the type of image files to create. The supported image
+        types, and details on modifying existing types and on creating new
+        types, are described in the <xref linkend="image_types" /> section.
+        This variable is set to a space seperated list of image types to
+        generate.</para>
+
+        <para>Example: <command>"jffs2 tar.gz"</command></para>
+
+        <para>Default: <command>"jffs2"</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>FEED_URIS</term>
+
+      <listitem>
+        <para>The name of the feeds to be configured in the image by default.
+        Each entry consists of the feed name, followed by two pound signs and
+        then followed by the actual feed URI.</para>
+
+        <para>Example: <command>FEED_URIS =
+        "example##http://dist.example.com/ipkg-titan-glibc/"</command></para>
+
+        <para>Default: <command>""</command></para>
+      </listitem>
+    </varlistentry>
+
+    <varlistentry>
+      <term>FEED_DEPLOYDIR_BASE_URI</term>
+
+      <listitem>
+        <para>If set, configures local testing feeds using OE package deploy dir
+	contents. The value is URL, corresponding to the ipk deploy dir.</para>
+
+        <para>Example: <command>FEED_DEPLOYDIR_BASE_URI =
+        "http://192.168.2.200/bogofeed/"</command></para>
+
+        <para>Default: <command>""</command></para>
+      </listitem>
+    </varlistentry>
+  </variablelist>
+
+  <section>
+    <title>Special node handling (fakeroot)</title>
+
+    <para>Special nodes, such as <command>/dev</command> nodes, and files with
+    special permissions, such as suid files, are handled via the <xref
+    linkend="fakeroot" /> system. This means that when you view the contents
+    of the root filesystem these device appear to be created
+    incorrectly:</para>
+
+    <para>The <command>IMAGE_PREPROCESS_COMMAND</command> and
+    <command>IMAGE_POSTPROCESS_COMMAND</command> variables will be processed
+    within the same <xref linkend="fakeroot" /> instance as the rest of the
+    rest of this class.</para>
+  </section>
+
+  <section>
+    <title>Device (/dev) nodes</title>
+
+    <para>There are two variables that can be defined for creating device
+    nodes. The new method supports multiple device node tables and supports
+    searching for these tables via the <command>${BBPATH}</command> so that
+    relative file names may be used.</para>
+
+    <para>The following example from <command>machine/titan.conf</command>
+    shows the use of multiple device tables:</para>
+
+    <para><screen># Add the SCI devices to minimal /dev
+IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt files/device_table_add-sci.txt device_table_add-sm.txt"
+</screen></para>
+
+    <para>It uses the standard minimal device tables but adds some additional
+    items which are not normally needed:</para>
+
+    <variablelist>
+      <varlistentry>
+        <term>files/device_table-minimal.txt</term>
+
+        <listitem>
+          <para>This is the standard minimal set of device nodes.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>files/device_table_add-sci.txt</term>
+
+        <listitem>
+          <para>This contains details for creating the
+          <command>/dev/SC{0,1,2}</command> nodes which are required for the
+          SH processors on board SCI and SCIF serial ports. On the titan
+          hardware the serial console is provided via one of these ports and
+          so we require the device node to be present.</para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>device_table_add-sm.txt</term>
+
+        <listitem>
+          <para>This contains details for creating the
+          <command>/dev/sm0</command> and <command>/dev/sm0p{0,1,2}</command>
+          devices nodes for the block driver, and the associated partitions,
+          that are used to manage the on board flash on the titan
+          hardware.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+
+    <para>Prior to support for multiple device tables this would have required
+    the creation of a titan specific device table.</para>
+  </section>
+
+  <section>
+    <title>Image types</title>
+
+    <para>The type of filesystem images to create are specified via the
+    <command>IMAGE_FSTYPES</command> variable. A full description of the
+    available image types, options of the images and details on creating new
+    image types is provided in the <xref linkend="image_types" />
+    section.</para>
+  </section>
+
+  <section>
+    <title>Package feeds</title>
+
+    <para>"Package feed", or feed for short, is a term used by <command>ipkg</command> 
+    package manager, commonly used in embedded systems, to name a package repository 
+    holding packages. Structurally, a feed is a directory - local, or on HTTP of FTP server, -
+    holding packages and package descriptor file, named <command>Packages</command> or 
+    <command>Packages.gz</command> if compressed. Multiple feeds are supported.</para>
+
+    <para>OpenEmbedded has support to pre-configure feeds within generated images, 
+    so once image is installed on a device, user can immediately install new software, 
+    without the need to manually edit config files. There are several ways to pre-configure 
+    feed support, described below.</para>
+    
+    <section>
+        <title>Method 1: Using existing feed</title>
+            <para>If you already have the feed(s) set up and available via specific URL, they
+	    can be added to the image using FEED_URIS variable:
+<screen>FEED_URIS = " \
+        base##http://oe.example.com/releases/${DISTRO_VERSION}/feed/base \
+        updates##http://oe.example.com/releases/${DISTRO_VERSION}/feed/updates"</screen>
+
+	    FEED_URIS contains list of feed descriptors, separated by spaces, per 
+	    OE conventions. Each descriptor consists of feed name and feed URL, 
+	    joined with "##". Feed name is an identifier used by ipkg to distinguish
+	    among the feeds. It can be arbitrary, just useful to the users to understood 
+	    which feed is used for one or another action.</para>
+    </section>
+
+    <section>
+        <title>Method 2: Using OE deploy directory as a feed (development only)</title>
+        <para>OE internally maintains a feed-like collection of directories to create
+	images from packages. This package deployment directory however has structure internal to OE
+	and subject to change without notice. Thus, using it as feed directly is not recommended
+	(distributions which ignored this recommendation are known to have their feeds broken when
+	OE upgraded its internal mechanisms).</para>
+        <para>However, using deploy directory as feed directly may be beneficial during
+	development and testing, as it allows developers to easily install newly built packages
+	without many manual actions. To facilitate this, OE offers a way to prepare feed configs
+	for using deploy dir as such. To start with this, you first need to configure local 
+	HTTP server to export a package deployment directory via HTTP.
+	Suppose you will export it via URL "http://192.168.2.200/bogofeed" (where 192.168.2.200 is the address
+	which will be reachable from the device). Add the following to your local.conf:
+<screen>
+FEED_DEPLOYDIR_BASE_URI = "http://192.168.2.200/bogofeed"
+</screen>
+	Now you need to setup local HTTP server to actually export that directory. For Apache it can be:
+<screen>
+<![CDATA[ 
+Alias /bogofeed ${DEPLOY_DIR} 
+ 
+<Directory ${DEPLOY_DIR}>
+    Options Indexes FollowSymLinks
+    Order deny,allow
+    Allow from 192.168.2.0/24
+</Directory>
+]]>
+</screen>
+	Replace ${DEPLOY_DIR} with the full path of deploy directory (last components of its path will be
+	<command>deploy/ipk</command>).</para>
+        <para>Now, every image built will automatically contain feed configs
+	for the deploy directory (as of time of writing, deploy directory is internally structured with
+	per-arch subdirectories; so, there several feed configs are being generated, one for each subdirectory).
+        </para>
+
+    </section>
+
+  </section>
+</section>
\ No newline at end of file
diff --git a/docs/usermanual/reference/class_pkgconfig.xml b/docs/usermanual/reference/class_pkgconfig.xml
new file mode 100644
index 0000000000..3cb5002df5
--- /dev/null
+++ b/docs/usermanual/reference/class_pkgconfig.xml
@@ -0,0 +1,39 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section id="pkgconfig_class" xreflabel="pkgconfig class">
+  <title>pkgconfig class</title>
+
+  <para>The pkgconfig class is for packages that install
+  <command>&lt;pkg&gt;.pc</command> files. These files provide information
+  about the build settings for the package vwhich are then made available by
+  the <command>pkg-config</command> command.</para>
+
+  <para>Since the contents of the <command>.pc</command> files are used at
+  build time they need to be installed into the staging area. All the actions
+  performed by this class are appended to the <emphasis>stage</emphasis>
+  task.</para>
+
+  <para>The actions performed by the pkgconfig class are:</para>
+
+  <orderedlist>
+    <listitem>
+      <para>Copies the <command>&lt;x&gt;.pc</command> files into the
+      <command>${PKG_CONFIG_PATH}</command> directory;</para>
+    </listitem>
+
+    <listitem>
+      <para>If the package is not native then it modifies the contents of the
+      <command>&lt;x&gt;.pc</command> file in the
+      <command>${PKG_CONFIG_PATH}</command> area to ensure that all the paths
+      in the script refer to the staging area;</para>
+    </listitem>
+  </orderedlist>
+
+  <para>A package is considered to be native if it also inherits the native
+  class.</para>
+
+  <para>The class will search the source directory, <command>${S}</command>,
+  and all it's subdirectories, for files that end in <command>.pc</command>
+  (it will ignore those that end in <command>-uninstalled.pc)</command> and
+  process them as described above. All that is required to use the class is
+  the addition of pkgconfig in an inherit statement:<screen>inherit autotools pkgconfig</screen></para>
+</section>
\ No newline at end of file
diff --git a/docs/usermanual/reference/class_rootfs_ipkg.xml b/docs/usermanual/reference/class_rootfs_ipkg.xml
new file mode 100644
index 0000000000..b60adf8e70
--- /dev/null
+++ b/docs/usermanual/reference/class_rootfs_ipkg.xml
@@ -0,0 +1,215 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<section id="rootfs_ipkg_class" xreflabel="rootfs_ipkg class">
+  <title>rootfs_ipkg class</title>
+
+  <para>The <emphasis>rootf_ipk</emphasis> class us used to create a root
+  filesystem for the target device from a set of .ipkg packages. The end
+  result is a directory containing all the files that need to be included in
+  the root filesystem of the target device.</para>
+
+  <para>This class is normally not used directly, but instead used from the
+  <xref linkend="image_class" /> which creates images from a set of package 
+  (typically <command>.ipkg</command>) files.</para>
+
+  <para>Summary of actions performed by the <emphasis>rootfs_ipkg</emphasis>
+  class:</para>
+
+  <orderedlist>
+    <listitem>
+      <para>Erase any existing root filesystem image by deleting the entire
+      contents of <command>${IMAGE_ROOTFS}</command>;</para>
+    </listitem>
+
+    <listitem>
+      <para>Creates the device node directory,
+      <command>${IMAGE_ROOTFS}/de