1 files changed, 704 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/es/user_customization-packages.ssi b/markup/pod/live-manual/media/text/es/user_customization-packages.ssi
new file mode 100644
index 0000000..390d921
--- /dev/null
+++ b/markup/pod/live-manual/media/text/es/user_customization-packages.ssi
@@ -0,0 +1,704 @@
+:B~ Personalización de la instalación de paquetes
+
+1~customizing-package-installation Personalización de la instalación de
+paquetes
+
+Quizás la tarea más básica de personalización de un sistema en vivo es la
+selección de paquetes que serán incluidos en la imagen. Este capítulo
+orienta a través de las diferentes opciones de live-build que, en el momento
+de la creación de la imagen, personalizan la instalación de paquetes. Las
+opciones que seleccionan la distribucion base y las áreas del archivo a
+utilizar son las que más influyen a la hora de conocer qué paquetes estarán
+disponibles para su instalación en la imagen. Para asegurar una buena
+velocidad de descarga de paquetes, se debería elegir el repositorio más
+cercano. Se pueden añadir repositorios para backports, experimentales,
+paquetes personalizados o incluir ficheros de paquetes directamente. Se
+pueden definir listas de paquetes personalizadas, incluyendo metapaquetes
+que instalarán muchos paquetes relacionados, como por ejemplo paquetes de un
+entorno de escritorio o lenguaje particular. Por último existen varias
+opciones que dan algún control sobre cuando son instalados los paquetes por
+la herramienta /{apt}/ o la herramienta /{aptitude}/, según sea la
+elegida. Estas opciones pueden ser útiles si se utiliza un proxy, se quiere
+desactivar la instalación de paquetes recomendados para ahorrar espacio o se
+necesita controlar las versiones de los paquetes a instalar mediante APT
+pinning, por nombrar algunas posibilidades.
+
+2~ Origen de los paquetes
+
+3~ Distribución, áreas de archivo y modo
+
+La distribución seleccionada tiene gran impacto en qué paquetes están
+disponibles para incluir en la imagen. Se debe indicar el nombre en clave de
+la distribución, que por defecto es ${testing} para la versión ${testing} de
+live-build. Se puede especificar cualquier nombre de distribución disponible
+en los repositorios indicando su nombre en clave. (Para más detalles ver
+{Términos}#terms). La opción #{--distribution}# no solamente influencia la
+fuente de los paquetes dentro del archivo, sino que instruye a live-build a
+comportarse tal y como se necesita para construir cada una de las
+distribuciones. Por ejemplo, para construir la versión *{inestable}*, sid,
+se debe indicar: 
+
+code{
+
+ $ lb config --distribution sid
+
+}code
+
+Las áreas del archivo Debian son la principal división de paquetes dentro de
+una distribución dada. En Debian las áreas del archivo establecidas son
+#{main}#, #{contrib}# y #{non-free}#. Solamente los paquetes contenidos en
+#{main}# son parte de la distribución Debian. Ésta es el área definida por
+defecto en live-build. Se pueden indicar uno o más valores tal y como se
+muestra en el siguiente ejemplo:
+
+code{
+
+ $ lb config --archive-areas "main contrib non-free"
+
+}code
+
+Experimentalmente se da soporte a alguna distribución derivada de Debian
+mediante la opción #{--mode}#. Por defecto, esta opción toma el valor
+#{debian}# sólo si se está construyendo en un sistema Debian o en un sistema
+desconocido. Si se utiliza #{lb config}# en cualquiera de las distribuciones
+derivadas a las que se da soporte, por defecto se construirá una imagen de
+esa distribución derivada. Por ejemplo, si #{lb config}# se ejecuta en modo
+#{ubuntu}# se utilizará el nombre de esa distribución y las áreas de
+archivos específicas de esa distribución derivada en lugar de los propios de
+Debian y live-build modificará su comportamiento para adecuarlo al modo
+seleccionado.
+
+*{Nota:}* La ayuda a los usuarios de las distribuciones para las cuales se añadieron estos modos son responsabilidad de los desarrolladores de dichas distribuciones. El ${project} proporciona ayuda al desarrollo de la mejor manera posible, basándose en la información recogida de dichas distribuciones derivadas a pesar de que no desarrolla ni da soporte a las mismas.
+
+3~ Réplicas de Distribución Debian
+
+Los repositorios de Debian están replicados en una gran red alrededor del
+mundo, de manera que se puede seleccionar la réplica más cercana con el fin
+de obtener la mejor velocidad de descarga. Cada una de las opciones
+#{--mirror-*}# gobierna qué réplica de repositorio Debian se utiliza en las
+diferentes etapas de creación. Si se recuerda de {Etapas de la
+creación}#stages-of-the-build, en la etapa *{bootstrap}* es cuando se crea
+el directorio chroot con un sistema mínimo mediante la herramienta
+/{debootstrap}/, y en la etapa *{chroot}* es cuando el directorio chroot es
+completado con los paquetes necesarios para crear el sistema de ficheros que
+será utilizado en el sistema en vivo. A cada una de estas etapas le
+corresponde su propia opción #{--mirror-*}#. Posteriormente, en la etapa
+*{binary}* se utilizarán las réplicas Debian indicadas en los valores de las
+opciones #{--mirror-binary}# y #{--mirror-binary-security}# en lugar de
+utilizar los indicados para las etapas anteriores.
+
+3~distribution-mirrors-build-time Réplicas de Distribution utilizadas
+durante la creación
+
+Para indicar qué réplicas deben ser utilizadas en el momento de crear la
+imagen es suficiente con utilizar las opciones #{--mirror-bootstrap}# y
+#{--mirror-chroot-security}# como se muestra a continuación.
+
+code{
+
+ $ lb config --mirror-bootstrap http://localhost/debian/ \
+          --mirror-chroot-security http://localhost/debian-security/
+
+}code
+
+El valor indicado en #{--mirror-chroot}# es utilizado como valor por defecto
+para la opción #{--mirror-bootstrap}# si esta no es especificada.
+
+3~ Réplicas de distribución Debian utilizadas en la ejecución.
+
+Las opciones #{--mirror-binary*}# gobiernan las réplicas configuradas en la
+imagen binaria que serán utilizadas para instalar paquetes adicionales
+mientras se ejecuta el sistema en vivo. Por defecto se utiliza
+#{httpredir.debian.org}#, que es un servicio que selecciona la réplica más
+cercana basándose, entre otras cosas,  en la familia de la IP del usuario y
+de la disponibilidad de la réplica. Es una elección bastante acertada
+siempre que no se pueda predecir que réplica será la mejor para todos los
+usuarios. También se puede especificar valores personalizados como se
+muestra en el siguiente ejemplo. Una imagen construida con esta
+configuración solamente sería accesible a los usuarios de una red donde
+"#{mirror}#" fuese alcanzable.
+
+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 Repositorios adicionales
+
+Se pueden añadir más repositorios, ampliando la lista de paquetes
+seleccionables más alla de aquellos disponibles para la distribución
+indicada, como pueden ser paquetes de backports, paquetes experimentales o
+personalizados. Para configurar repositorios adicionales se debe crear los
+ficheros #{config/archives/your-repository.list.chroot}# y/o
+#{config/archives/your-repository.list.binary}#. Al igual que en las
+opciones #{--mirror-*}#, estos ficheros gobiernan los repositorios
+utilizados en las etapas *{chroot}* y *{binary}* respectivamente, esto es,
+los repositorios que serán utilizados cuando se ejecute el sistema en vivo.
+
+Por ejemplo, #{config/archives/live.list.chroot}# permite instalar paquetes
+de las instantáneas del repositorio Debian Live en el momento de crear la
+imagen.
+
+code{
+
+ deb http://live-systems.org/ sid-snapshots main contrib non-free
+
+}code
+
+Si se añade la misma línea a #{config/archives/live.list.binary}#, el
+repositorio será añadido al directorio #{/etc/apt/sources.list.d/}# del
+sistema en vivo.
+
+Estos ficheros serán seleccionados automáticamente si existen.
+
+Se debería también incluir en el fichero
+#{config/archives/your-repository.key.{binary,chroot}}# la clave GPG a
+utilizar para firmar dicho repositorio.
+
+En caso de necesitar un APT pinning personalizado, las preferencias de APT
+se pueden colocar mediante ficheros
+#{config/archives/your-repository.pref.{binary,chroot}}#, y serán añadidos
+automáticamente al sistema en vivo en el directorio
+#{/etc/apt/preferences.d/}#.
+
+2~choosing-packages-to-install Selección de los paquetes a instalar
+
+Hay varias maneras de seleccionar qué paquetes serán instalados por
+live-build en la imagen que cubren una variedad de necesidades diversas. Se
+puede nombrar paquetes individuales para instalar en una lista de
+paquetes. También se puede utilizar metapaquetes en esas listas, o
+selecionarlas utilizando campos de ficheros de control de paquetes. Por
+último, también se pueden utilizar ficheros de paquetes de prueba o
+experimentales obtenidos antes de que aparezcan en los repositorios
+oficiales simplemente depositando estos ficheros directamente en el árbol de
+directorios #{config/}#.
+
+3~package-lists Listas de paquetes
+
+Las listas de paquetes proporcionan una potente forma de expresar qué
+paquetes deberían ser instalados. La sintaxis de las listas soporta las
+expresiones condicionales, que facilitan la creación de listas, adaptando su
+utilización a diversas configuraciones. También se pueden añadir nombre de
+paquetes en la listas utilizando shell helpers en tiempo de construcción. 
+
+*{Nota:}* El comportamiento de live-build cuando se especifica un paquete que no existe es determinado por lo que se haya configurado en la utilidad APT. Para más detalles ver {Utilizar apt o aptitude}#choosing-apt-or-aptitude.
+
+3~using-metapackages  Utilizar metapaquetes
+
+La manera más sencilla de rellenar una lista de paquetes es utilizar una
+tarea metapaquete mantenida por una distribución. Por ejemplo:
+
+code{
+
+ $ lb config
+ $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot
+
+}code
+
+Esto reemplaza el antiguo método de listas predefinidas compatible con
+#{live-build}# 2.x. A diferencia de las listas predefinidas, los
+metapaquetes de tareas no son específicos del proyecto Live Systems. Por el
+contrario, son mantenidas por grupos de especialistas que trabajan en la
+distribución y por lo tanto, reflejan el consenso de cada grupo acerca de
+qué paquetes sirven mejor a las necesidades de los usuarios. Además, abarcan
+una gama mucho más amplia de casos de uso que las listas predefinidas a las
+que sustituyen.
+
+Todos los metapaquetes de tareas tienen el prefijo #{task-}#,  por lo que
+una forma rápida de determinar cuales están disponibles (aunque puede
+contener un puñado de entradas falsas que coincidan con el nombre, pero que
+no son metapaquetes) es buscar el nombre del paquete con:
+
+code{
+
+ $ apt-cache search --names-only ^task-
+
+}code
+
+Además de éstos, se encuentran otros metapaquetes con diversos
+fines. Algunos son subconjuntos de paquetes de tareas más amplias, como
+#{gnome-core}#, mientras que otros son partes especializadas individuales de
+un Debian Pure Blend, como los metapaquetes #{education-*}#. Para tener una
+lista de todos los metapaquetes en el archivo, instalar el paquete
+#{debtags}# y listar todos los paquetes con la etiqueta
+#{role::metapackage}# de la siguiente manera:
+
+code{
+
+ $ debtags search role::metapackage
+
+}code
+
+3~ Listas de paquetes locales
+
+Ya sea incluyendo metapaquetes en una lista, paquetes individuales, o una
+combinación de ambos, todas las listas de paquetes locales se deben
+almacenar en #{config/package-lists/}#. Ya que se puede utilizar más de una
+lista, esto se presta muy bien a los diseños modulares. Por ejemplo, se
+puede dedicar una lista a una elección particular de escritorio, la otra a
+una colección de paquetes relacionados que puedan ser fácilmente utilizados
+sobre un escritorio diferente. Esto permite experimentar con diferentes
+combinaciones de conjuntos de paquetes con un mínimo esfuerzo, así como
+compartir listas comunes entre diferentes proyectos de imágenes en vivo.
+
+Para que sean procesadas, las listas de paquetes que se depositen en este
+directorio deben tener la extensión #{.list}# además de la extensión de la
+etapa #{.chroot}# o #{.binary}# para indicar a qué etapa corresponde la
+lista.
+
+*{Nota:}* Si no se especifica el sufijo, la lista será usada en las dos etapas. En consecuencia, es conveniente especificar #{.list.chroot}# de modo que los paquetes se instalen únicamente en el sistema en vivo y no exista otra copia extra del paquete #{.deb}#.
+
+3~ Listas de paquetes locales para la etapa binary
+
+Para crear una lista para la etapa «binary» crear un fichero con el sufijo
+#{.list.binary}# en #{config/package-lists/}#. Estos paquetes no son
+instalados en el sistema en vivo, pero son incluidos en #{pool/}#. El uso
+típico de una de estas lista sería para una de las variantes de instalador
+normal («non-live» N.del T.). Tal y como se mencionaba anteriormente, si se
+desea usar la misma lista para la etapa «chroot» basta con solamente añadir
+el sufijo #{.list}#
+
+3~generated-package-lists Generar listas de paquetes
+
+A veces ocurre que la mejor manera de crear una lista es generarla con un
+script. Cualquier línea que comience con un signo de exclamación indica un
+comando que se ejecutará dentro del chroot cuando la imagen se
+construya. Por ejemplo, se podría incluir la línea #{! grep-aptavail -n
+-sPackage -FPriority standard | sort}# en una lista de paquetes para
+producir una lista ordenada de los paquetes disponibles con #{Priority:
+standard}#.
+
+De hecho, la selección de paquetes con la orden #{grep-aptavail}# (del
+paquete #{dctrl-tools}#) es tan útil que #{live-build}# proporciona un
+script de ayuda llamado #{Packages}#. Este script acepta dos argumentos:
+#{field}# y #{pattern}#. Por lo tanto, se puede crear una lista con los
+siguientes contenidos:
+
+code{
+
+ $ lb config
+ $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
+
+}code
+
+3~ Utilización de condiciones dentro de las listas de paquetes
+
+En las sentencias condicionales de las listas de paquetes pueden utilizarse
+cualquier variable disponible en #{config/*}# (excepto las que tienen el
+prefijo #{LB_}#). En general esto significa que puede utilizarse cualquier
+opción válida para #{lb config}# cambiando las letras minúsculas por
+mayúsculas y los guiones por barras bajas. En la práctica solamente tiene
+sentido utilizar aquellas variables relacionadas con la selección de
+paquetes, como pueden ser #{DISTRIBUTION}#, #{ARCHITECTURES}# o
+#{ARCHIVE_AREAS}#.
+
+Por ejemplo, para instalar el paquete #{ia32-libs}# si se ha especificado la
+arquitectura amd64 (#{--architectures amd64}#) se puede utilizar:
+
+code{
+
+ #if ARCHITECTURES amd64
+ ia32-libs
+ #endif
+
+}code
+
+En la expresión condicional pueden utilizarse varios valores. Por ejemplo
+para instalar el paquete /{memtest86+}/ si la arquitectura es i386
+(#{--architectures i386}#) o es amd64 (#{--architectures amd64}#) se puede
+especificar:
+
+code{
+
+ #if ARCHITECTURES i386 amd64
+ memtest86+
+ #endif
+
+}code
+
+En la expresión condicional también pueden utilizarse variables que pueden
+contener más de un valor. Por ejemplo para instalar /{vrms}/ si se utilizan
+las áreas del archivo #{contrib}# o #{non-free}# mediante la opción
+#{--archive-areas}# se puede indicar:
+
+code{
+
+ #if ARCHIVE_AREAS contrib non-free
+ vrms
+ #endif
+
+}code
+
+No se permite el anidamiento de estructuras condicionales.
+
+% FIXME:
+
+3~ Eliminación paquetes durante la instalación
+
+Se puede crear listas de paquetes en ficheros con los sufijos
+#{.list.chroot_live}# y #{.list.chroot_install}# dentro del directorio
+#{config/package-lists}#. Si existe una lista «live» y una lista «install»
+los paquetes de la lista #{.list.chroot_live}# se eliminan con un script
+gancho después de la instalación (si el usuario utiliza el instalador). Los
+paquetes de la lista #{.list.chroot_install}# estarán presentes tanto en el
+sistema en vivo como en el sistema instalado. Este es un caso especial para
+el instalador y puede ser útil si se tiene #{--debian-installer live}#
+establecido en la configuración y se desea eliminar paquetes específicos del
+sistema en vivo durante la instalación.
+
+3~desktop-and-language-tasks Tareas de Escritorio e Idioma
+
+Las tareas de escritorio y de idioma son casos especiales que necesitan un
+poco de planificación y configuración extra. Si el medio de instalación fue
+preparado para una clase particular de entorno de escritorio, el Instalador
+de Debian instalará automáticamente la tarea de entorno de escritorio
+correspondiente. Para ello existen las tareas  internas #{gnome-desktop}#,
+#{kde-desktop}#, #{lxde-desktop}# y #{xfce-desktop}# pero ninguna de ellas
+son presentadas en el menú de #{tasksel}#. De igual forma, las tareas para
+idiomas tampoco son presentadas en el menú de #{tasksel}#, pero la selección
+del idioma, al inicio de la instalación repercute en la selección de las
+correspondientes tareas del idioma.
+
+Cuando se desarolla una imagen de escritorio, la imagen normalmente arranca
+directamente a un escritorio de trabajo, las opciones de escritorio y de
+idioma por defecto han sido elegidas en tiempo de creación, no en tiempo de
+ejecución como en el caso del instalador de Debian. Eso no quiere decir que
+una imagen en vivo no pueda ser creada para admitir múltiples escritorios o
+varios idiomas y ofrecer al usuario una elección, pero ese no es un
+comportamiento por defecto de live-build.
+
+Ya que no se ha previsto la instalación automática de tareas de idiomas, que
+incluyen cosas tales como tipos de letra específicos de cada lengua o
+paquetes de métodos de entrada, si se quiere incluirlos, es necesario
+especificarlo en la configuración. Por ejemplo, una imagen de escritorio
+GNOME que contenga soporte para el alemán podría incluir los siguientes
+metapaquetes de tareas:
+
+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 Versión y tipo de kernel 
+
+Dependiendo de la arquitectura, se incluyen por defecto en las imágenes uno
+o más tipos de kernels. Se puede elegir entre diferentes tipos utilizando la
+opción #{--linux-flavours}#. Cada tipo tiene el sufijo de la raíz
+predeterminada #{linux-image}# para formar el nombre de cada metapaquete que
+a su vez depende del paquete del kernel exacto que debe incluirse en la
+imagen.
+
+Así, por defecto, una imagen de arquitectura #{amd64}# incluirá el
+metapaquete #{linux-image-amd64}# y una imagen de arquitectura #{i386}#
+incluirá el metapaquete #{linux-image-586}#.
+
+Cuando hay más de una versión diferente del paquete del kernel disponible en
+los archivos configurados, se puede especificar el nombre de un paquete del
+kernel diferente con la opción #{--linux-packages}#. Por ejemplo, suponer
+que se está construyendo una image de arquitectura #{amd64}# y se quiere
+añadir el archivo experimental a fin de realizar pruebas. Para que se pueda
+instalar el kernel #{linux-image-3.18.0-trunk-amd64}#, se podría configurar
+la imagen de la siguiente manera:
+
+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 Kernels personalizados
+
+Se pueden crear e incluir kernels personalizados, pero hay que tener en
+cuenta que live-build sólo soporta los kernels que se integran en el sistema
+de gestión de paquetes de Debian y no es compatible con kernels que no esten
+en paquetes #{.deb}#.
+
+La manera apropiada y recomendada de implementar los propios paquetes del
+kernel es seguir las instrucciones del #{kernel-handbook}#. Recordar
+modificar el ABI y los sufijos de los tipos del kernel e incluir los
+paquetes del kernel completo en un repositorio que coincidan con los
+paquetes #{linux}# y #{linux-latest}#.
+
+Si se opta por construir los paquetes del kernel sin los metapaquetes
+adecuados, es necesario especificar una raíz #{--linux-packages}# apropiada
+como se indica en {Versión y tipo de kernel}#kernel-flavour-and-version. Tal
+y como se explica en {Instalar paquetes modificados o de
+terceros}#installing-modified-or-third-party-packages, es mejor si se
+incluyen los paquetes del kernel personalizado en un repositorio propio,
+aunque las alternativas discutidas en esa sección también funcionan.
+
+Está más allá del alcance de este documento dar consejos sobre cómo
+personalizar un kernel. Sin embargo, se debe por lo menos, asegurarse de que
+la configuración cumple los siguientes requisitos mínimos:
+
+_* Utilizar un ramdisk inicial.
+
+_* Incluir el módulo de unión de sistemas de ficheros (normalmente
+#{aufs}#).
+
+_* Incluir todos los módulos de sistemas de ficheros requeridos por la
+configuración (normalmente #{squashfs}#).
+
+2~installing-modified-or-third-party-packages Instalar paquetes modificados
+o de terceros
+
+Si bien está en contra de la filosofía de un sistema en vivo, en ocasiones
+es necesario crear un sistema con versiones de paquetes modificados a partir
+de los disponibles en el repositorio de Debian. Estos paquetes pueden
+modificar características existentes o dar soporte a características
+adicionales, idiomas y marcas, o eliminar elementos existentes en los
+paquetes que no son de interes. De manera similar, se pueden incluir
+paquetes «de terceros» para añadir funcionalidades a medida o propietarias.
+
+En esta sección no se describe la creación o mantenimiento de paquetes
+personalizados. Puede ser interesante una lectura del método descrito por
+Joachim Breitner 'How to fork privately' en
+http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html.
+La guía del nuevo desarrollador de Debian en
+https://www.debian.org/doc/maint-guide/ describe la creación de paquetes a
+medida.
+
+Existen dos formas de instalar paquetes personalizados:
+
+_* #{packages.chroot}#
+
+_* Utilizando un repositorio APT personalizado
+
+El método #{packages.chroot}# es el más simple para añadir paquetes
+personalizados. Es muy útil para personalizaciones «rápidas» pero tiene unos
+cuantos inconvenientes mientras que la utilización de un repositorio APT
+personalizado es más lento de poner en marcha.
+
+3~ Método #{packages.chroot}# para instalar paquetes personalizados
+
+Para instalar paquetes personalizados solamente hay que copiar el paquete en
+el directorio #{config/packages.chroot/}#. Los paquetes contenidos en este
+directorio serán automáticamente instalados en el sistema en vivo durante el
+proceso de creación. No es necesario especificar nada más.
+
+Los paquetes *{deben}* nombrarse de la forma prescrita. La forma más simple
+es usar #{dpkg-name}#.
+
+El método #{packages.chroot}# para la instalación de paquetes personalizados
+tiene desventajas:
+
+_* No es posible utilizar secure APT.
+
+_* Se deben depositar todos los paquetes apropiados en el directorio
+#{config/packages.chroot/}#.
+
+_* No es adecuado para almacenar configuraciones en vivo en un control de
+versiones.
+
+3~ Método de repositorio APT para instalar paquetes personalizados
+
+A diferencia del método #{packages.chroot}#, cuando se utiliza el método de
+repositorio APT personalizado se debe asegurar que se especifica dónde se
+deben buscar los paquetes a instalar. Para más información ver {Selección de
+los paquetes a instalar}#choosing-packages-to-install.
+
+Aunque crear un repositorio APT para instalar paquetes personalizados puede
+parecer un esfuerzo innecesaro, la infraestructurar puede ser fácilmente
+reutilizada posteriormente para ofrecer nuevas versiones de los paquetes.
+
+3~ Paquetes personalizados y APT
+
+live-build utiliza APT para instalar todos los paquetes en el sistema en
+vivo, así que hereda sus comportamientos. Un punto a resaltar es que
+(asumiendo una configuración de APT por defecto) dado un paquete en dos
+repositorios diferentes con diferentes números de versiones, APT
+seleccionará para instalar el paquete con número de versión superior.
+
+Esta sería una buena razón para incrementar el número de version en los
+ficheros #{debian/changelog}# de los paquetes personalizados y así asegurar
+que serán estos los paquetes instalados en lugar de los contenidos en los
+repositorios oficiales de Debian. Esto puede también lograrse alterando las
+preferencias de pinning de APT del sistema en vivo. Para más información ver
+{APT pinning}#apt-pinning.
+
+2~ Configurar APT en la creación
+
+Se puede configurar APT mediante varias opciones que se aplicarán en el
+momento de crear la imagen. (La configuración que APT utilizará cuando se
+ejecute el sistema en vivo puede ser configurada de la manera que
+habitualmente se utiliza para introducir contenidos del sistema en vivo,
+esto es, incluyendo las configuraciones apropiadas en el directorio
+#{config/includes.chroot/}#.) Se puede encontrar una lista completa de las
+opciones para configurar APT en la página de manual de #{lb_config}#. Son
+aquellas opciones que comienzan con #{apt}#.
+
+3~choosing-apt-or-aptitude Utilizar apt o aptitude
+
+Se puede seleccionar qué herramienta se utilizará para instalar paquetes,
+/{apt}/ o /{aptitude}/, en el momento de crear la imagen mediante la opción
+#{--apt}# de #{lb config}#. Esta selección definirá el comportamiento
+preferido en la instalación de paquetes, siendo la mayor diferencia la
+manera de tratar los paquetes no disponibles.
+
+_* #{apt}#: Con este método, si se especifica un paquete no existente, la
+instalación fallará. Es el comportamiento por defecto.
+
+_* #{aptitude}#: Con este método, si se especifica un paquete no existente,
+la instalación continuará sin error.
+
+3~ Utilización de un proxy con APT
+
+Un problema habitual en la configuración de APT es tratar con la creación de
+una imagen desde detras de un proxy. Se puede especificar dicho proxy con
+las opciones  #{--apt-ftp-proxy}# o #{--apt-http-proxy}#. Por ejemplo:
+
+code{
+
+ $ lb config --apt-http-proxy http://proxy/
+
+}code
+
+3~tweaking-apt-to-save-space Ajuste de APT para ahorrar espacio
+
+En ocasiones es necesario ahorrar un poco de espacio en el medio de
+instalación. Las dos opciones descritas a continuación pueden ser de
+interes.
+
+Si no se desea incluir los índices de APT en la imagen creada se puede
+utilizar la siguiente opción:
+
+code{
+
+ $ lb config --apt-indices false
+
+}code
+
+Esto no modificará el comportamiento de las entradas definidas en
+#{/etc/apt/sources.list}#, sino que solo afecta a si exitirán o no ficheros
+de índice en el directorio #{/var/lib/apt}#. El compromiso viene de que APT
+necesita estos ficheros índices para funcionar en el sistema en vivo, así
+que, si no existen, el usuario deberá ejecutar la orden #{apt-get update}#
+para crear estos índices antes de poder ejecutar una orden del tipo
+#{apt-cache search}# o #{apt-get install}#.
+
+Si la instalación de los paquetes recomendados aumenta demasiado el tamaño
+de la imagen, siempre y cuando se esté preparado para hacer frente a las
+consecuencias que se mencionan a continuación, se puede desactivar el valor
+por defecto de esta opción de APT con:
+
+code{
+
+ $ lb config --apt-recommends false
+
+}code
+
+La consecuencia más importante de desactivar los «recommends» es que
+#{live-boot}# y #{live-config}# recomiendan algunos paquetes que
+proporcionan una funcionalidad importante y que son utilizados por la
+mayoría de las configuraciones en vivo, como por ejemplo #{user-setup}#
+recomendado por #{live-config}# que se utiliza para crear el usuario en
+vivo. En todas menos en las circunstancias más excepcionales es necesario
+volver a añadir por lo menos algunos de los «recommends» en las listas de
+paquetes o de lo contrario la imagen no funcionará como se espera, si es que
+funciona en lo más minimo. Mirar los paquetes recomendados por cada uno de
+los paquetes #{live-*}# incluidos en la construcción y si no se está seguro
+de que es lo que se puede omitir, volver a agregarlo utilizando las listas
+de paquetes.
+
+La consecuencia más general es que, si no se instalan los paquetes
+recomendados para un paquete dado, esto es «los paquetes que supuestamente
+deberían encontrase intalados si un paquete ya lo está» (Debian Policy
+Manual, seccion 7.2), algún paquete que supuestamente debería estar
+instalado será omitido. Por lo tanto, se sugiere que si se desactiva esta
+opción, se revise las diferencias en las listas de paquetes instalados (ver
+el fichero #{binary.packages}# generado por #{lb build}#) y que se vuelva a
+incluir en la lista cualquier paquete que deba ser instalado. Si se
+considera que el número de paquetes a descartar es pequeño, se recomienda
+que la opción se deje activada y que se utilice una prioridad pin negativa
+de APT en dichos paquetes y así evitar que sean instalados tal y como se
+explica en {APT pinning}#apt-pinning.
+
+3~ Pasar opciones a apt o a aptitude
+
+Si no hay una opción #{lb config}# para modificar el comportamiento de APT
+en la forma que se necesita, utilizar #{--apt-options}# o
+#{--aptitude-options}# para pasar opciones a la herramienta APT
+configurada. Consultar las páginas de manual #{apt}# y #{aptitude}# para más
+detalles. Tener en cuenta que ambas opciones tienen valores por defecto que
+tendran que mantenerse, además de las opciones que se pueden
+especificar. Así, por ejemplo, supongamos que se ha incluido algo con fines
+de prueba de #{snapshot.debian.org}# y se desea especificar
+#{Acquire::Check-Valid-Until=false}# para que APT esté feliz con el fichero
+#{Release}# caducado, se haría como en el ejemplo siguiente, añadiendo la
+opción de nuevo después del valor por defecto #{--yes}#:
+
+code{
+
+ $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"
+
+}code
+
+Consultar las páginas de manual para entender completamente estas opciones y
+cuándo utilizarlas. Esto es sólo un ejemplo y no debe ser interpretado como
+consejo para configurar la imagen. Esta opción no sería apropiada para, por
+ejemplo, una versión final de una imagen en vivo.
+
+Para configuraciones más complicadas que implican opciones #{apt.conf}#
+puede ser necesario crear un fichero #{config/apt/apt.conf}#. Ver tambien
+las otras opciones #{apt-*}# para tener algunos atajos convenientes para las
+opciones que se necesitan con frecuencia.
+
+3~apt-pinning APT pinning
+
+Como información básica, sería recomendable leer la página de manual
+#{apt_preferences(5)}#. APT pinning puede ser configurado o en tiempo de
+creación de la imagen, creando los ficheros #{config/archives/*.pref}#,
+#{config/archives/*.pref.chroot}#, y #{config/apt/preferences}#. o en tiempo
+de ejecución del sistema en vivo creando el fichero
+#{config/includes.chroot/etc/apt/preferences}#.
+
+Supongamos que se está creando un sistema en vivo basado en ${testing} pero
+se necesita instalar todos los paquetes "live" que terminan instalados en la
+imagen binaria final desde la versión inestable «sid» en el momento de crear
+la imagen. Se deberá añadir sid a los orígenes (sources) de APT y fijar
+(pin) los paquetes live con una prioridad más alta pero todos los otros
+paquetes con una prioridad más baja que la prioridad por defecto de manera
+que solamente los paquetes fijados sean instalados desde sid mientras que el
+resto será obtenido desde la distribución base, ${testing}. Esto se puede
+realizar de la siguiente forma:
+
+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
+
+Una prioridad pin negativa previene la instalación de un paquete, como puede
+ser el caso de que no se desee que un paquete recomendado por otro sea
+instalado al instalar el primero. Supongamos que se está creando una imagen
+LXDE añadiendo #{task-lxde-desktop}# en
+#{config/package-lists/desktop.list.chroot}#, pero no se desea preguntar al
+usuario si desea almacenar las claves wifi en el keyring. Este metapaquete
+depende de /{lxde-core}/, el cual recomienda /{gksu}/ que a su vez
+recomienda /{gnome-keyring}/. Así que el objetivo es omitir la instalación
+del paquete /{gnome-keyring}/, que puede conseguirse añadiendo un fichero
+con el siguiente contenido a #{config/apt/preferences}#:
+
+code{
+
+ Package: gnome-keyring
+ Pin: version *
+ Pin-Priority: -1
+
+}code