[SCM] live-manual branch, debian, updated. debian/2.0_a5-1-11-gbbfc27d
Daniel Baumann
daniel at debian.org
Tue Sep 7 13:18:23 UTC 2010
The following commit has been merged in the debian branch:
commit fed315addd233d6e812187bf15290c9bb4136075
Author: Daniel Baumann <daniel at debian.org>
Date: Tue Sep 7 15:14:48 2010 +0200
Updating other_overview for squeeze.
diff --git a/manual/en/other_overview.ssi b/manual/en/other_overview.ssi
index 2f5b532..43fda74 100644
--- a/manual/en/other_overview.ssi
+++ b/manual/en/other_overview.ssi
@@ -4,95 +4,99 @@
This chapter contains an overview of the two main tools used in building Debian Live systems.
-2~ live-helper
+2~ live-build
-live-helper is a collection of scripts to build Debian Live systems. These scripts are also referred to as "helpers".
+live-build is a collection of scripts to build Debian Live systems. These scripts are also referred to as "commands".
-The idea behind live-helper is to be a framework that uses a configuration directory to completely automate and customize all aspects of building a Live image.
+The idea behind live-build is to be a framework that uses a configuration directory to completely automate and customize all aspects of building a Live image.
Many concepts are similar to those in the debhelper Debian package tools written by Joey Hess:
-_* The scripts have a central location for configuring their operation. In debhelper, this is the debian subdirectory of a package tree. For example, dh_install will look for a file called #{debian/.install}# to determine which files should exist in a particular binary package. In much the same way, live-helper stores its configuration entirely under a config subdirectory.
+_* The scripts have a central location for configuring their operation. In debhelper, this is the debian subdirectory of a package tree. For example, dh_install will look, amongst others, for a file called #{debian/install}# to determine which files should exist in a particular binary package. In much the same way, live-build stores its configuration entirely under a config subdirectory.
_* The scripts are independent - that is to say, it is always safe to run each command.
-Unlike debhelper, live-helper contains a tool to generate a skeleton configuration directory, lh config. This could be considered to be similar to tools such as dh-make. For more information about lh config, please see lh-config.
-% FIXME: <xref linkend="lh-config"/>
+Unlike debhelper, live-build contains a tool to generate a skeleton configuration directory, #{lb config}#. This could be considered to be similar to tools such as #{dh-make}#. For more information about #{lb config}#, please see lb-config.
+% FIXME: <xref linkend="lb-config"/>
-Besides the common config/common, which is used by all live-helper helper commands, some additional files can be used to configure the behavior of specific helper commands. These files are typically named config/helper or config/stage (where "stage", of course, is replaced with the name of the stage that they belong to, and "helper" with the name of the helper).
+Besides the common config/common, which is used by all live-build commands, some additional files can be used to configure the behavior of specific helper commands. These files are typically named config/command or config/stage (where "stage", of course, is replaced with the name of the stage that they belong to, and "command" with the name of the command).
-For example, the lh bootstrap debootstrap helper command uses files named config/bootstrap and config/bootstrap_debootstrap to read the options it will use. Generally, these files contain variables with values assigned, one variable per line. Some programs in live-helper use pairs of values or slightly more complicated variable assignments.
+For example, the #{lb_bootstrap_debootstrap}# command uses files named config/bootstrap and config/bootstrap_debootstrap to read the options it will use. Generally, these files contain variables with values assigned, one variable per line. Some commands of live-buil use pairs of values or slightly more complicated variable assignments.
-live-helper respects environment variables which are present in the context of the shell it is running. If variables can be read from config files, then they override environment variables, and if command line options are used, they override values from config files. If no value for a given variable can be found (and is thus unset), live-helper will automatically set it to a default value.
+live-build respects environment variables which are present in the context of the shell it is running. If variables can be read from config files, then they override environment variables, and if command line options are used, they override values from config files. If no value for a given variable can be found (and is thus unset), live-build will automatically set it to a default value.
-All config files are shell scripts which are sourced by a live-helper program. That means they have to follow the normal shell syntax. You can also put comments in these files; lines beginning with "#" are ignored.
+All config files are shell scripts which are sourced by a live-build command. That means they have to follow the normal shell syntax. You can also put comments in these files; lines beginning with "#" are ignored.
-In some rare cases you may want to have different versions of these files for different architectures or distributions. If files named config/stage.arch or config/stage_helper.arch, and config/stage.dist or config/stage_helper.dist exist (where "arch" is the same as the output of dpkg --print-architecture and "dist" is the same as the codename of the target distribution), then they will be used in preference to the other, more general files.
+In some rare cases you may want to have different versions of these files for different architectures or distributions. If files named config/stage.arch or config/stage_command.arch, and config/stage.dist or config/stage_command.dist exist (where "arch" is the same as the output of dpkg --print-architecture and "dist" is the same as the codename of the target distribution), then they will be used in preference to the other, more general files.
-Please see installation for information on how to install live-helper.
+Please see installation for information on how to install live-build.
% FIXME: <xref linkend="installation"/>
-The remainder of this section discusses the three most important helpers:
+The remainder of this section discusses the three most important commands:
-_* *{lh config}*: Responsible for initialising a Live system configuration directory. See lh-config for more information.
-% FIXME: <xref linkend="lh-config"/>
+_* *{lb config}*: Responsible for initialising a Live system configuration directory. See lb-config for more information.
+% FIXME: <xref linkend="lb-config"/>
-_* *{lh build}*: Responsible for starting a Live system build. See lh-build for more information.
-% FIXME: <xref linkend="lh-build"/>
+_* *{lb build}*: Responsible for starting a Live system build. See lb-build for more information.
+% FIXME: <xref linkend="lb-build"/>
-_* *{lh clean}*: Responsible for removing parts of a Live system build. See lh-clean for more information.
-% FIXME: <xref linkend="lh-clean"/
+_* *{lb clean}*: Responsible for removing parts of a Live system build. See lb-clean for more information.
+% FIXME: <xref linkend="lb-clean"/
-3~ The lh config helper
+3~ The #{lb config}# command
-As discussed in live-helper, the scripts that make up live-helper source their configuration from a single directory named config/. As constructing this directory by hand would be time-consuming and error-prone, the lh config helper can be used to create skeleton configuration folders.
-% FIXME: <xref linkend="live-helper"/>
+As discussed in live-build, the scripts that make up live-build source their configuration from a single directory named config/. As constructing this directory by hand would be time-consuming and error-prone, the #{lb config}# command can be used to create skeleton configuration folders.
+% FIXME: <xref linkend="live-build"/>
-Issuing lh config without any arguments creates a config subdirectory which it populates with some default settings:
+Issuing #{lb config}# without any arguments creates a config subdirectory which it populates with some default settings:
code{
-$ lh config
+$ lb config
+P: Creating config tree
+
$ ls -l
-total 4.1k
-drwxr-xr-x 19 user group 4.1k 2008-05-09 21:37 config
+total 8
+drwxr-xr-x 3 user user 4096 Sep 7 13:02 auto
+drwxr-xr-x 22 user user 4096 Sep 7 13:02 config
+
$ ls -l config/
total 104
--rw-r--r-- 1 user group 4175 2010-04-11 12:16 binary
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_debian-installer
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_debian-installer-includes
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_grub
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_local-debs
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_local-hooks
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_local-includes
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_local-packageslists
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_local-udebs
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_rootfs
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 binary_syslinux
--rw-r--r-- 1 user group 2205 2010-04-11 12:16 bootstrap
--rw-r--r-- 1 user group 1599 2010-04-11 12:16 chroot
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_apt
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_local-hooks
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_local-includes
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_local-packages
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_local-packageslists
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_local-patches
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_local-preseed
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 chroot_sources
--rw-r--r-- 1 user group 2938 2010-04-11 12:16 common
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 includes
--rw-r--r-- 1 user group 206 2010-04-11 12:16 source
-drwxr-xr-x 2 user group 4096 2010-04-11 12:16 templates
+-rw-r--r-- 1 user user 4197 Sep 7 13:02 binary
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_debian-installer-includes
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_grub
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-debs
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-hooks
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-includes
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-packageslists
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_local-udebs
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_rootfs
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 binary_syslinux
+-rw-r--r-- 1 user user 2051 Sep 7 13:02 bootstrap
+-rw-r--r-- 1 user user 1647 Sep 7 13:02 chroot
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_apt
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-hooks
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-includes
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packages
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-packageslists
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-patches
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_local-preseed
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 chroot_sources
+-rw-r--r-- 1 user user 2954 Sep 7 13:02 common
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 includes
+-rw-r--r-- 1 user user 205 Sep 7 13:02 source
+drwxr-xr-x 2 user user 4096 Sep 7 13:02 templates
}code
-Using lh config without any arguments would be suitable for users who are either happy editing the generated files, or are simply happy with the defaults it creates.
+Using #{lb config}# without any arguments would be suitable for users who are either happy editing the generated files, or are simply happy with the defaults it creates.
-You can ask lh config to generate a config/ directory "preseeded" with various options. This might be suitable if you do not require the default settings but do not need to change a large number of options. For example:
+You can ask #{lb config}# to generate a config/ directory "preseeded" with various options. This might be suitable if you do not require the default settings but do not need to change a large number of options. For example:
code{
-$ lh config -p gnome
+$ lb config -p gnome
}code
@@ -100,26 +104,24 @@ will build a config/ directory configured to include the 'gnome' package list. I
code{
-$ lh config --apt aptitude --binary-images net --hostname live-machine --username live-user ...
+$ lb config --binary-images net --hostname live-machine --username live-user ...
}code
-A full list of options is available in the lh_config man page. Most options have a parallel with an "LH_" prefixed variable.
-
-3~ The lh build helper
+A full list of options is available in the #{lb_config}# man page. Most options have a parallel with an "LB_" prefixed variable.
-The lh build helper reads in your configuration from the config/ directory. It then runs the lower lower level commands needed to build your Live system.
+3~ The #{lb build}# command
-3~ The lh clean helper
+The #{lb build}# command reads in your configuration from the config/ directory. It then runs the lower lower level commands needed to build your Live system.
-It is the job of the lh clean helper to remove various parts of a Live helper build so subsequent builds can start from a clean state.
+3~ The #{lb clean}# command
-2~ The live-initramfs package
+It is the job of the #{lb clean}# command to remove various parts of a build so subsequent builds can start from a clean state.
-live-initramfs is a collection of scripts providing hooks for the initramfs-tools, used to generate an initramfs capable of booting live systems, such as those created by live-helper. This includes the Debian Live isos, netboot tarballs, and usb stick images.
+2~ The live-boot package
-At boot time it will look for read-only media containing a "/live" directory where a root filesystem (often a compressed filesystem image like squashfs) is stored. If found, it will create a writable environment, using aufs or unionfs, for Debian like systems to boot from.
+live-boot is a collection of scripts providing hooks for the initramfs-tools, used to generate an initramfs capable of booting live systems, such as those created by live-build. This includes the Debian Live isos, netboot tarballs, and usb stick images.
-live-initramfs is a fork of casper, http://packages.ubuntu.com/casper.
+At boot time it will look for read-only media containing a "/live" directory where a root filesystem (often a compressed filesystem image like squashfs) is stored. If found, it will create a writable environment, using aufs, for Debian like systems to boot from.
More information on initial ramfs in Debian can be found in the Debian Linux Kernel Handbook at http://kernel-handbook.alioth.debian.org/ in the chapter on initramfs.
--
live-manual
More information about the debian-live-changes
mailing list