[SCM] live-manual branch, debian, updated. debian/3.0_a17-1

Daniel Baumann daniel at debian.org
Thu Sep 27 10:55:57 UTC 2012


The following commit has been merged in the debian branch:
commit f1c0e6b69f54d1265f7d27dc4f56a5ecd3b099c3
Author: Daniel Baumann <daniel at debian.org>
Date:   Tue Sep 25 17:52:30 2012 +0200

    Updating and extending section on kernel flavour and version a bit.

diff --git a/manual/en/user_customization-packages.ssi b/manual/en/user_customization-packages.ssi
index b2b3e90..9ca1786 100644
--- a/manual/en/user_customization-packages.ssi
+++ b/manual/en/user_customization-packages.ssi
@@ -211,20 +211,26 @@ code{
 
 3~kernel-flavour-and-version Kernel flavour and version
 
-Your choice of architecture determines the default flavour or flavours of kernel included in the image, and each flavour is suffixed to the default kernel package name stub #{linux-image}# to form each metapackage name which in turn depends on an exact kernel to include in your image. Thus, an #{amd64}# architecture image will include the #{linux-image-amd64}# flavour metapackage, and an #{i386}# architecture image will include the #{linux-image-486}# and #{linux-image-686-pae}# metapackages. At time of writing, these packages depend on #{linux-image-3.2.0-3-amd64}#, #{linux-image-3.2.0-3-486}# and #{linux-image-3.2.0-3-686-pae}#, respectively.
+Your choice of architecture determines the default flavour or flavours of kernel images included in the live system. Each flavour is suffixed to the default stub #{linux-image}# to form each metapackage name which in turn depends on an exact kernel package to be included in your image.
+
+Thus by default, an #{amd64}# architecture image will include the #{linux-image-amd64}# flavour metapackage, and an #{i386}# architecture image will include the #{linux-image-486}# and #{linux-image-686-pae}# metapackages. At time of writing, these packages depend on #{linux-image-3.2.0-4-amd64}#, #{linux-image-3.2.0-4-486}# and #{linux-image-3.2.0-4-686-pae}#, respectively.
 
 When more than one kernel package version is available in your configured archives, you can specify a different kernel package name stub with the #{--linux-packages}# option. For example, supposing you are building an #{amd64}# architecture image and add the experimental archive for testing purposes so you can install the #{linux-image-3.5-trunk-amd64}# kernel. You would configure that image as follows:
 
 code{
- 
- $ lb config -a amd64 --linux-packages linux-image-3.5-trunk
- $ echo "deb http://mirror/debian sid main" > config/archives/sid.list.chroot
+
+ $ lb config --linux-packages linux-image-3.5-trunk
+ $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot
 
 }code
 
-Please note that live-build supports only kernels that are integrated within the Debian package management system and does not support kernels not built as #{.deb}# packages.
+Please note that live-build directly supports only kernels that are integrated within the Debian package management system and does not support kernels not built as #{.deb}# packages.
+
+The proper and recommended way to deploy your own kernel packages is to follow the instructions in the #{kernel-handbook}#, bump the kernel ABI and include a complete build of the #{linux}# and matching #{linux-latest}# packages in your repository.
+
+When not using a full kernel build with matching metapackages, kernels without metapackages can be included in your configuration just the way you would any other package and specifying an appropriate #{--linux-packages}# stub.
 
-You may build and use your own custom kernel package in a similar fashion, including it in your configuration just the way you would any other package and specifying an appropriate #{--linux-packages}# stub. Of course you must satisfy the minimum requirements for running a live environment, i.e. at least include any kernel modules needed to handle the live filesystem (usually aufs and squashfs) and don't forget to suffix the package names with the flavour (e.g. #{-amd64}#).
+Remember when building custom kernel configurations you must of course satisfy the minimum requirements for running a live environment, i.e. at least include any kernel modules needed to handle the live filesystem (usually aufs and squashfs) and don't forget to suffix the package names with the flavour (e.g. #{-amd64}#).
 
 2~installing-modified-or-third-party-packages Installing modified or third-party packages
 

-- 
live-manual



More information about the debian-live-changes mailing list