diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/pt_BR/user_customization-packages.ssi')
| -rw-r--r-- | markup/pod/live-manual/media/text/pt_BR/user_customization-packages.ssi | 643 |
1 files changed, 0 insertions, 643 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 deleted file mode 100644 index dd6bd88..0000000 --- a/markup/pod/live-manual/media/text/pt_BR/user_customization-packages.ssi +++ /dev/null @@ -1,643 +0,0 @@ -: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 |