1 files changed, 0 insertions, 704 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
deleted file mode 100644
index 390d921..0000000
--- a/markup/pod/live-manual/media/text/es/user_customization-packages.ssi
+++ /dev/null
@@ -1,704 +0,0 @@
-: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