track document samples used

1 files changed, 643 insertions, 0 deletions

diff --git a/markup/pod/live-manual/media/text/pt_BR/user_customization-packages.ssi b/markup/pod/live-manual/media/text/pt_BR/user_customization-packages.ssi
new file mode 100644
index 0000000..dd6bd88
--- /dev/null
+++ b/markup/pod/live-manual/media/text/pt_BR/user_customization-packages.ssi
@@ -0,0 +1,643 @@
+:B~ Customizing package installation
+
+1~customizing-package-installation Customizing package installation
+
+Perhaps the most basic customization of a live system is the selection of
+packages to be included in the image. This chapter guides you through the
+various build-time options to customize live-build's installation of
+packages. The broadest choices influencing which packages are available to
+install in the image are the distribution and archive areas. To ensure
+decent download speeds, you should choose a nearby distribution mirror. You
+can also add your own repositories for backports, experimental or custom
+packages, or include packages directly as files. You can define lists of
+packages, including metapackages which will install many related packages at
+once, such as packages for a particular desktop or language. Finally, a
+number of options give some control over /{apt}/, or if you prefer,
+/{aptitude}/, at build time when packages are installed. You may find these
+handy if you use a proxy, want to disable installation of recommended
+packages to save space, or need to control which versions of packages are
+installed via APT pinning, to name a few possibilities.
+
+2~ Package sources
+
+3~ Distribution, archive areas and mode
+
+The distribution you choose has the broadest impact on which packages are
+available to include in your live image. Specify the codename, which
+defaults to ${testing} for the ${testing} version of live-build. Any current
+distribution carried in the archive may be specified by its codename
+here. (See {Terms}#terms for more details.) The #{--distribution}# option
+not only influences the source of packages within the archive, but also
+instructs live-build to behave as needed to build each supported
+distribution. For example, to build against the *{unstable}* release, sid,
+specify:
+
+code{
+
+ $ lb config --distribution sid
+
+}code
+
+Within the distribution archive, archive areas are major divisions of the
+archive. In Debian, these are #{main}#, #{contrib}# and #{non-free}#. Only
+#{main}# contains software that is part of the Debian distribution, hence
+that is the default. One or more values may be specified, e.g.
+
+code{
+
+ $ lb config --archive-areas "main contrib non-free"
+
+}code
+
+Experimental support is available for some Debian derivatives through a
+#{--mode}# option. By default, this option is set to #{debian}# only if you
+are building on a Debian or on an unknown system. If #{lb config}# is
+invoked on any of the supported derivatives, it will default to create an
+image of that derivative. If #{lb config}# is run in e.g. #{ubuntu}# mode,
+the distribution names and archive areas for the specified derivative are
+supported instead of the ones for Debian. The mode also modifies live-build
+behaviour to suit the derivatives.
+
+*{Note:}* The projects for whom these modes were added are primarily responsible for supporting users of these options. The ${project}, in turn, provides development support on a best-effort basis only, based on feedback from the derivative projects as we do not develop or support these derivatives ourselves.
+
+3~ Distribution mirrors
+
+The Debian archive is replicated across a large network of mirrors around
+the world so that people in each region can choose a nearby mirror for best
+download speed. Each of the #{--mirror-*}# options governs which
+distribution mirror is used at various stages of the build. Recall from
+{Stages of the build}#stages-of-the-build that the *{bootstrap}* stage is
+when the chroot is initially populated by /{debootstrap}/ with a minimal
+system, and the *{chroot}* stage is when the chroot used to construct the
+live system's filesystem is built. Thus, the corresponding mirror switches
+are used for those stages, and later, in the *{binary}* stage, the
+#{--mirror-binary}# and #{--mirror-binary-security}# values are used,
+superseding any mirrors used in an earlier stage.
+
+3~distribution-mirrors-build-time Distribution mirrors used at build time
+
+To set the distribution mirrors used at build time to point at a local
+mirror, it is sufficient to set #{--mirror-bootstrap}# and
+#{--mirror-chroot-security}# as follows.
+
+code{
+
+ $ lb config --mirror-bootstrap http://localhost/debian/ \
+          --mirror-chroot-security http://localhost/debian-security/
+
+}code
+
+The chroot mirror, specified by #{--mirror-chroot}#, defaults to the
+#{--mirror-bootstrap}# value.
+
+3~ Distribution mirrors used at run time
+
+The #{--mirror-binary*}# options govern the distribution mirrors placed in
+the binary image. These may be used to install additional packages while
+running the live system. The defaults employ #{httpredir.debian.org}#, a
+service that chooses a geographically close mirror based, among other
+things, on the user's IP family and the availability of the mirrors. This is
+a suitable choice when you cannot predict which mirror will be best for all
+of your users. Or you may specify your own values as shown in the example
+below. An image built from this configuration would only be suitable for
+users on a network where "#{mirror}#" is reachable.
+
+code{
+
+ $ lb config --mirror-binary http://mirror/debian/ \
+          --mirror-binary-security http://mirror/debian-security/ \
+          --mirror-binary-backports http://mirror/debian-backports/
+
+}code
+
+3~additional-repositories Additional repositories
+
+You may add more repositories, broadening your package choices beyond what
+is available in your target distribution. These may be, for example, for
+backports, experimental or custom packages. To configure additional
+repositories, create #{config/archives/your-repository.list.chroot}#, and/or
+#{config/archives/your-repository.list.binary}# files. As with the
+#{--mirror-*}# options, these govern the repositories used in the *{chroot}*
+stage when building the image, and in the *{binary}* stage, i.e. for use
+when running the live system.
+
+For example, #{config/archives/live.list.chroot}# allows you to install
+packages from the debian-live snapshot repository at live system build time.
+
+code{
+
+ deb http://live-systems.org/ sid-snapshots main contrib non-free
+
+}code
+
+If you add the same line to #{config/archives/live.list.binary}#, the
+repository will be added to your live system's #{/etc/apt/sources.list.d/}#
+directory.
+
+If such files exist, they will be picked up automatically.
+
+You should also put the GPG key used to sign the repository into
+#{config/archives/your-repository.key.{binary,chroot}}# files.
+
+Should you need custom APT pinning, such APT preferences snippets can be
+placed in #{config/archives/your-repository.pref.{binary,chroot}}# files and
+will be automatically added to your live system's
+#{/etc/apt/preferences.d/}# directory.
+
+2~choosing-packages-to-install Choosing packages to install
+
+There are a number of ways to choose which packages live-build will install
+in your image, covering a variety of different needs. You can simply name
+individual packages to install in a package list. You can also use
+metapackages in those lists, or select them using package control file
+fields. And finally, you may place package files in your #{config/}# tree,
+which is well suited to testing of new or experimental packages before they
+are available from a repository.
+
+3~package-lists Package lists
+
+Package lists are a powerful way of expressing which packages should be
+installed. The list syntax supports conditional sections which makes it easy
+to build lists and adapt them for use in multiple configurations. Package
+names may also be injected into the list using shell helpers at build time.
+
+*{Note:}* The behaviour of live-build when specifying a package that does not exist is determined by your choice of APT utility. See {Choosing apt or aptitude}#choosing-apt-or-aptitude for more details.
+
+3~using-metapackages Using metapackages
+
+The simplest way to populate your package list is to use a task metapackage
+maintained by your distribution. For example:
+
+code{
+
+ $ lb config
+ $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot
+
+}code
+
+This supercedes the older predefined list method supported in #{live-build}#
+2.x. Unlike predefined lists, task metapackages are not specific to the Live
+System project. Instead, they are maintained by specialist working groups
+within the distribution and therefore reflect the consensus of each group
+about which packages best serve the needs of the intended users. They also
+cover a much broader range of use cases than the predefined lists they
+replace.
+
+All task metapackages are prefixed #{task-}#, so a quick way to determine
+which are available (though it may contain a handful of false hits that
+match the name but aren't metapackages) is to match on the package name
+with:
+
+code{
+
+ $ apt-cache search --names-only ^task-
+
+}code
+
+In addition to these, you will find other metapackages with various
+purposes. Some are subsets of broader task packages, like #{gnome-core}#,
+while others are individual specialized parts of a Debian Pure Blend, such
+as the #{education-*}# metapackages. To list all metapackages in the
+archive, install the #{debtags}# package and list all packages with the
+#{role::metapackage}# tag as follows:
+
+code{
+
+ $ debtags search role::metapackage
+
+}code
+
+3~ Local package lists
+
+Whether you list metapackages, individual packages, or a combination of
+both, all local package lists are stored in #{config/package-lists/}#. Since
+more than one list can be used, this lends itself well to modular
+designs. For example, you may decide to devote one list to a particular
+choice of desktop, another to a collection of related packages that might as
+easily be used on top of a different desktop. This allows you to experiment
+with different combinations of sets of packages with a minimum of fuss,
+sharing common lists between different live image projects.
+
+Package lists that exist in this directory need to have a #{.list}# suffix
+in order to be processed, and then an additional stage suffix, #{.chroot}#
+or #{.binary}# to indicate which stage the list is for.
+
+*{Note:}* If you don't specify the stage suffix, the list will be used for both stages. Normally, you want to specify #{.list.chroot}# so that the packages will only be installed in the live filesystem and not have an extra copy of the #{.deb}# placed on the medium.
+
+3~ Local binary package lists
+
+To make a binary stage list, place a file suffixed with #{.list.binary}# in
+#{config/package-lists/}#. These packages are not installed in the live
+filesystem, but are included on the live medium under #{pool/}#. You would
+typically use such a list with one of the non-live installer variants. As
+mentioned above, if you want this list to be the same as your chroot stage
+list, simply use the #{.list}# suffix by itself.
+
+3~generated-package-lists Generated package lists
+
+It sometimes happens that the best way to compose a list is to generate it
+with a script. Any line starting with an exclamation point indicates a
+command to be executed within the chroot when the image is built. For
+example, one might include the line #{! grep-aptavail -n -sPackage
+-FPriority standard | sort}# in a package list to produce a sorted list of
+available packages with #{Priority: standard}#.
+
+In fact, selecting packages with the #{grep-aptavail}# command (from the
+#{dctrl-tools}# package) is so useful that #{live-build}# provides a
+#{Packages}# helper script as a convenience. This script takes two
+arguments: #{field}# and #{pattern}#. Thus, you can create a list with the
+following contents:
+
+code{
+
+ $ lb config
+ $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
+
+}code
+
+3~ Using conditionals inside package lists
+
+Any of the live-build configuration variables stored in #{config/*}# (minus
+the #{LB_}# prefix) may be used in conditional statements in package
+lists. Generally, this means any #{lb config}# option uppercased and with
+dashes changed to underscores. But in practice, it is only the ones that
+influence package selection that make sense, such as #{DISTRIBUTION}#,
+#{ARCHITECTURES}# or #{ARCHIVE_AREAS}#.
+
+For example, to install #{ia32-libs}# if the #{--architectures amd64}# is
+specified:
+
+code{
+
+ #if ARCHITECTURES amd64
+ ia32-libs
+ #endif
+
+}code
+
+You may test for any one of a number of values, e.g. to install
+/{memtest86+}/ if either #{--architectures i386}# or #{--architectures
+amd64}# is specified:
+
+code{
+
+ #if ARCHITECTURES i386 amd64
+ memtest86+
+ #endif
+
+}code
+
+You may also test against variables that may contain more than one value,
+e.g. to install /{vrms}/ if either #{contrib}# or #{non-free}# is specified
+via #{--archive-areas}#:
+
+code{
+
+ #if ARCHIVE_AREAS contrib non-free
+ vrms
+ #endif
+
+}code
+
+The nesting of conditionals is not supported.
+
+% FIXME:
+
+3~ Removing packages at install time
+
+You can list packages in files with #{.list.chroot_live}# and
+#{.list.chroot_install}# suffixes inside the #{config/package-lists}#
+directory. If both a live and an install list exist, the packages in the
+#{.list.chroot_live}# list are removed with a hook after the installation
+(if the user uses the installer). The packages in the
+#{.list.chroot_install}# list are present both in the live system and in the
+installed system. This is a special tweak for the installer and may be
+useful if you have #{--debian-installer live}# set in your config, and wish
+to remove live system-specific packages at install time.
+
+3~desktop-and-language-tasks Desktop and language tasks
+
+Desktop and language tasks are special cases that need some extra planning
+and configuration. Live images are different from Debian Installer images in
+this respect. In the Debian Installer, if the medium was prepared for a
+particular desktop environment flavour, the corresponding task will be
+automatically installed. Thus, there are internal #{gnome-desktop}#,
+#{kde-desktop}#, #{lxde-desktop}# and #{xfce-desktop}# tasks, none of which
+are offered in #{tasksel}#'s menu. Likewise, there are no menu entries for
+tasks for languages, but the user's language choice during the install
+influences the selection of corresponding language tasks.
+
+When developing a desktop live image, the image typically boots directly to
+a working desktop, the choices of both desktop and default language having
+been made at build time, not at run time as in the case of the Debian
+Installer. That's not to say that a live image couldn't be built to support
+multiple desktops or multiple languages and offer the user a choice, but
+that is not live-build's default behaviour.
+
+Because there is no provision made automatically for language tasks, which
+include such things as language-specific fonts and input-method packages, if
+you want them, you need to specify them in your configuration. For example,
+a GNOME desktop image containing support for German might include these task
+metapackages:
+
+code{
+
+ $ lb config
+ $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
+ $ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot
+
+}code
+
+3~kernel-flavour-and-version Kernel flavour and version
+
+One or more kernel flavours will be included in your image by default,
+depending on the architecture. You can choose different flavours via the
+#{--linux-flavours}# option. 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-586}# metapackage.
+
+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.18.0-trunk-amd64}#
+kernel. You would configure that image as follows:
+
+code{
+
+ $ lb config --linux-packages linux-image-3.18.0-trunk
+ $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot
+
+}code
+
+3~custom-kernels Custom kernels
+
+You can build and include your own custom kernels, so long as they are
+integrated within the Debian package management system. The live-build
+system 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}#. Remember to modify the
+ABI and flavour suffixes appropriately, then include a complete build of the
+#{linux}# and matching #{linux-latest}# packages in your repository.
+
+If you opt to build the kernel packages without the matching metapackages,
+you need to specify an appropriate #{--linux-packages}# stub as discussed in
+{Kernel flavour and version}#kernel-flavour-and-version. As we explain in
+{Installing modified or third-party
+packages}#installing-modified-or-third-party-packages, it is best if you
+include your custom kernel packages in your own repository, though the
+alternatives discussed in that section work as well.
+
+It is beyond the scope of this document to give advice on how to customize
+your kernel. However, you must at least ensure your configuration satisfies
+these minimum requirements:
+
+_* Use an initial ramdisk.
+
+_* Include the union filesystem module (i.e. usually #{aufs}#).
+
+_* Include any other filesystem modules required by your configuration
+(i.e. usually #{squashfs}#).
+
+2~installing-modified-or-third-party-packages Installing modified or
+third-party packages
+
+While it is against the philosophy of a live system, it may sometimes be
+necessary to build a live system with modified versions of packages that are
+in the Debian repository. This may be to modify or support additional
+features, languages and branding, or even to remove elements of existing
+packages that are undesirable. Similarly, "third-party" packages may be used
+to add bespoke and/or proprietary functionality.
+
+This section does not cover advice regarding building or maintaining
+modified packages. Joachim Breitner's 'How to fork privately' method from
+http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
+may be of interest, however. The creation of bespoke packages is covered in
+the Debian New Maintainers' Guide at https://www.debian.org/doc/maint-guide/
+and elsewhere.
+
+There are two ways of installing modified custom packages:
+
+_* #{packages.chroot}#
+
+_* Using a custom APT repository
+
+Using #{packages.chroot}# is simpler to achieve and useful for "one-off"
+customizations but has a number of drawbacks, while using a custom APT
+repository is more time-consuming to set up.
+
+3~ Using #{packages.chroot}# to install custom packages
+
+To install a custom package, simply copy it to the
+#{config/packages.chroot/}# directory. Packages that are inside this
+directory will be automatically installed into the live system during build
+- you do not need to specify them elsewhere.
+
+Packages *{must}* be named in the prescribed way. One simple way to do this
+is to use #{dpkg-name}#.
+
+Using #{packages.chroot}# for installation of custom packages has
+disadvantages:
+
+_* It is not possible to use secure APT.
+
+_* You must install all appropriate packages in the
+#{config/packages.chroot/}# directory.
+
+_* It does not lend itself to storing live system configurations in revision
+control.
+
+3~ Using an APT repository to install custom packages
+
+Unlike using #{packages.chroot}#, when using a custom APT repository you
+must ensure that you specify the packages elsewhere. See {Choosing packages
+to install}#choosing-packages-to-install for details.
+
+While it may seem unnecessary effort to create an APT repository to install
+custom packages, the infrastructure can be easily re-used at a later date to
+offer updates of the modified packages.
+
+3~ Custom packages and APT
+
+live-build uses APT to install all packages into the live system so will
+therefore inherit behaviours from this program. One relevant example is that
+(assuming a default configuration) given a package available in two
+different repositories with different version numbers, APT will elect to
+install the package with the higher version number.
+
+Because of this, you may wish to increment the version number in your custom
+packages' #{debian/changelog}# files to ensure that your modified version is
+installed over one in the official Debian repositories. This may also be
+achieved by altering the live system's APT pinning preferences - see {APT
+pinning}#apt-pinning for more information.
+
+2~ Configuring APT at build time
+
+You can configure APT through a number of options applied only at build
+time. (APT configuration used in the running live system may be configured
+in the normal way for live system contents, that is, by including the
+appropriate configurations through #{config/includes.chroot/}#.) For a
+complete list, look for options starting with #{apt}# in the #{lb_config}#
+man page.
+
+3~choosing-apt-or-aptitude Choosing apt or aptitude
+
+You can elect to use either /{apt}/ or /{aptitude}/ when installing packages
+at build time. Which utility is used is governed by the #{--apt}# argument
+to #{lb config}#. Choose the method implementing the preferred behaviour for
+package installation, the notable difference being how missing packages are
+handled.
+
+_* #{apt}#: With this method, if a missing package is specified, the package
+installation will fail. This is the default setting.
+
+_* #{aptitude}#: With this method, if a missing package is specified, the
+package installation will succeed.
+
+3~ Using a proxy with APT
+
+One commonly required APT configuration is to deal with building an image
+behind a proxy. You may specify your APT proxy with the #{--apt-ftp-proxy}#
+or #{--apt-http-proxy}# options as needed, e.g.
+
+code{
+
+ $ lb config --apt-http-proxy http://proxy/
+
+}code
+
+3~tweaking-apt-to-save-space Tweaking APT to save space
+
+You may find yourself needing to save some space on the image medium, in
+which case one or the other or both of the following options may be of
+interest.
+
+If you don't want to include APT indices in the image, you can omit those
+with:
+
+code{
+
+ $ lb config --apt-indices false
+
+}code
+
+This will not influence the entries in #{/etc/apt/sources.list}#, but merely
+whether #{/var/lib/apt}# contains the indices files or not. The tradeoff is
+that APT needs those indices in order to operate in the live system, so
+before performing #{apt-cache search}# or #{apt-get install}#, for instance,
+the user must #{apt-get update}# first to create those indices.
+
+If you find the installation of recommended packages bloats your image too
+much, provided you are prepared to deal with the consequences discussed
+below, you may disable that default option of APT with:
+
+code{
+
+ $ lb config --apt-recommends false
+
+}code
+
+The most important consequence of turning off recommends is that
+#{live-boot}# and #{live-config}# themselves recommend some packages that
+provide important functionality used by most Live configurations, such as
+#{user-setup}# which #{live-config}# recommends and is used to create the
+live user. In all but the most exceptional circumstances you need to add
+back at least some of these recommends to your package lists or else your
+image will not work as expected, if at all. Look at the recommended packages
+for each of the #{live-*}# packages included in your build and if you are
+not certain you can omit them, add them back into your package lists.
+
+The more general consequence is that if you don't install recommended
+packages for any given package, that is, "packages that would be found
+together with this one in all but unusual installations" (Debian Policy
+Manual, section 7.2), some packages that users of your Live system actually
+need may be omitted. Therefore, we suggest you review the difference turning
+off recommends makes to your packages list (see the #{binary.packages}# file
+generated by #{lb build}#) and re-include in your list any missing packages
+that you still want installed. Alternatively, if you find you only want a
+small number of recommended packages left out, leave recommends enabled and
+set a negative APT pin priority on selected packages to prevent them from
+being installed, as explained in {APT pinning}#apt-pinning.
+
+3~ Passing options to apt or aptitude
+
+If there is not a #{lb config}# option to alter APT's behaviour in the way
+you need, use #{--apt-options}# or #{--aptitude-options}# to pass any
+options through to your configured APT tool. See the man pages for #{apt}#
+and #{aptitude}# for details. Note that both options have default values
+that you will need to retain in addition to any overrides you may
+provide. So, for example, suppose you have included something from
+#{snapshot.debian.org}# for testing purposes and want to specify
+#{Acquire::Check-Valid-Until=false}# to make APT happy with the stale
+#{Release}# file, you would do so as per the following example, appending
+the new option after the default value #{--yes}#:
+
+code{
+
+ $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"
+
+}code
+
+Please check the man pages to fully understand these options and when to use
+them. This is an example only and should not be construed as advice to
+configure your image this way. This option would not be appropriate for,
+say, a final release of a live image.
+
+For more complicated APT configurations involving #{apt.conf}# options you
+might want to create a #{config/apt/apt.conf}# file instead. See also the
+other #{apt-*}# options for a few convenient shortcuts for frequently needed
+options.
+
+3~apt-pinning APT pinning
+
+For background, please first read the #{apt_preferences(5)}# man page. APT
+pinning can be configured either for build time, or else for run time. For
+the former, create #{config/archives/*.pref}#,
+#{config/archives/*.pref.chroot}#, and #{config/apt/preferences}#. For the
+latter, create #{config/includes.chroot/etc/apt/preferences}#.
+
+Let's say you are building a ${testing} live system but need all the live
+packages that end up in the binary image to be installed from sid at build
+time. You need to add sid to your APT sources and pin the live packages from
+it higher, but all other packages from it lower, than the default
+priority. Thus, only the packages you want are installed from sid at build
+time and all others are taken from the target system distribution,
+${testing}. The following will accomplish this:
+
+code{
+
+ $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
+ $ cat >> config/archives/sid.pref.chroot << EOF
+ Package: live-*
+ Pin: release n=sid
+ Pin-Priority: 600
+
+ Package: *
+ Pin: release n=sid
+ Pin-Priority: 1
+ EOF
+
+}code
+
+Negative pin priorities will prevent a package from being installed, as in
+the case where you do not want a package that is recommended by another
+package. Suppose you are building an LXDE image using #{task-lxde-desktop}#
+in #{config/package-lists/desktop.list.chroot}#, but don't want the user
+prompted to store wifi passwords in the keyring. This metapackage depends on
+/{lxde-core}/, which recommends /{gksu}/, which in turn recommends
+/{gnome-keyring}/. So you want to omit the recommended /{gnome-keyring}/
+package. This can be done by adding the following stanza to
+#{config/apt/preferences}#:
+
+code{
+
+ Package: gnome-keyring
+ Pin: version *
+ Pin-Priority: -1
+
+}code