Translation(s): English - Español - Italiano - Русский - 简体中文

Este artículo trata de explicar como usar las 'preferencias' de APT. En este momento solo pinning está documentado aquí.

Contents

  1. Pinning
    1. /etc/apt/sources.list
    2. /etc/apt/preferences
    3. Instalando desde unstable
    4. Notas de JoshuaRodman
    5. Notas de ZugSchlus
    6. Notas de Ryan B.
    7. Notas de GeorgiosZarkadas
    8. Notas de Dmitriy Matrosov
  2. Referencias

Pinning

Antes de que considere hacer 'pinning', quizá quiera comprobar si el paquete que desea ha sido backported a su versión de Debian.

<!> Cuando haga uso de apt-pinning, debe asegurarse por su cuenta de que los paquetes sean compatibles, ya que Debian no lo garantiza. Tenga en cuenta que apt-pinning es opcional, y Debian no fomenta su uso sin un examen exhaustivo.

Pinning le permite instalar ciertos paquetes de una versión (stable, testing, unestable) sin que tenga que actualizar el sistema entero. Sin embargo, al instalar paquetes de futuras versiones, probablemente instale o actualice bibliotecas también, así que puede que termine con un sistema con las desventajas de la versión stable (software viejo), las desventajas de unstable/testing (el soporte relacionado con la seguridad no es tan bueno como en stable) y sin las ventajas de uno u otro.

Al más bajo nivel, pinning está involucrado con dos ficheros,

Un papel adicional es el target release¡¡, que puede ser configurado en apt.conf (o en /etc/apt/conf.d/..., o mediante la línea de comando usando apt.

/etc/apt/sources.list

 #### testing  #########
 deb http://ftp.us.debian.org/debian testing main contrib non-free

 #### unstable #########
 deb http://ftp.us.debian.org/debian unstable main contrib non-free

En este ejemplo, estamos usando testing y unstable. Usted puede, por su puesto, modificar el ejemplo para usar stable también.

/etc/apt/preferences

En el fichero 'preferences' es donde pinning' se lleva a cabo. Aquí tenemos un ejemplo: 

 Package: *
 Pin: release a=testing
 Pin-Priority: 900

 Package: *
 Pin: release a=unstable
 Pin-Priority: 800

Package por defecto todos, especificado con el asterisco. Pin especifica la versión de release (testing and unstable). Pin-Priority especifica el nivel de prioridad. 'apt-get' por defecto sigue la filosofía de "la versión mas moderna del paquete gana". Lo de arriba, cambia un poco esto, de tal manera que los paquetes en testing tengan mas prioridad, incluso cuando estos no sean la última versión disponible.

Usted deberia también consultar la manpage apt_preferences(5).

Instalando desde unstable

Vamos a asumir que estamos en testing y queremos probar una versión mas moderna de enlightenment desde unstable. Basicamente hay dos métodos para instalarla: 

 # apt-get install enlightenment/unstable
 # apt-get -t unstable install enlightenment

El primer comando tratará de no actualizar ningún paquete en el sistema, así que si las dependencias no se satisfacen, la instalación fallará. El segundo método instalará/actualizará cualquier dependencia. Por su puesto, en 'apt-get' le preguntará antes de proceder a ello.

Notas de JoshuaRodman

Personalmente, encuentro que la configuración de alta prioridad a Testing y menor prioridad a Unstable puede ser problemática. En algunos casos, paquetes de testing dependerán de otros que no están actualmente en testing (lo cual es un pequeño fallo de testing) lo cual causará que los paquetes sean automáticamente instalados desde unstable. En el periodo de pruebas antes de mover Woody a stable, esto causo que terminase con alrededor de 100 paquetes instalados desde unstable sin darme cuenta.

Como resultado, yo uso una configuración mas conservadora "solo si yo lo digo", con una configuración como esta: 

  Package: *
  Pin: release a=testing
  Pin-Priority: 900

  Package: *
  Pin: release o=Debian
  Pin-Priority: -10

De esta manera todos los paquetes de Debian tienen por defecto -10 de prioridad, mientras que testing tiene una bonificación de 900. Esto provoca los siguientes comportamientos:

Sacado de apt_preferences(5)

  500 < P <=990 :
        causes a version to be installed unless there is a version 
        available belonging to the target release or the installed 
        version is more recent
  [...]
  P < 0 :
        prevents the version from being installed

Tenga en cuenta que una prioridad por encima de 1000 permitirá incluso regresar a una versión anterior del paquete sin importar cual sea la versión del paquete prioritario. Esto significa que se puede utilizar la prioridad 1001 para un repositorio stable si usted desea regresar a una versión anterior de los paquetes que ha instalado (por ejemplo de testing) Esto no es recomendable a menos que el número de cambios sean mínimos.

Los paquetes unstable solo serán instalados con los siguientes comandos: apt-get install packagename/unstable y apt-get install -t unstable packagename.

Notas de ZugSchlus

Aviso

Esta página ha sido escrita por ZugSchlus, que no capta el concepto de pinning. Así que por favor, interprete las palabras "probablemente", "necesita ser verificado" y similares, de una manera literal y documente sus descubrimientos aquí.

Descripción del Proceso de Selección de Paquetes

-->Here Esto es lo que un usuario cree que deberia ser.

ToDo: Esto necesita ser verificado

Ejemplo de /etc/apt/preferences

Ejemplo 1

 Package: *
 Pin: release o=Debian,a=testing
 Pin-Priority: 900

 Package: *
 Pin: release o=Debian,a=unstable
 Pin-Priority: 300

 Package: *
 Pin: release o=Debian
 Pin-Priority: -1

Falta: Documentación que explique lo que esta configuración hace.

ZugSchlus trata de explicarlo:

Problema: Esta configuración se comporta de manera diferente, dependiendo que "target release" está configurada en otras partes de la configuración de apt. Por lo tanto, este ejemplo no puede ser documentado sin añadir mas información. Un paquete "non-pinned" que es parte del "target-release" tiene como prioridad 900, mientas que otros paquetes "non-pinned" tienen por defecto 500.

Ejemplo 2

Objetivo: En un sistema unstable, instalar dpatch desde experimental.

Una posible solución:

Ejemplo 3

De Mihamina rakotomandimby

Suponga que tiene un repositorio personal, donde tiene una versión personal de Postfix. Quieres que Apt prefiera tu versión antes que la oficial.

Puede configurar las preferencias por Origen 

Package: *
Pin: origin www.rktmb.org
Pin-Priority: 610

Package: *
Pin: origin ftp.fr.debian.org
Pin-Priority: 600

Debugging

apt-cache policy package brinda información acerca del proceso de selección. Desafortunadamente, no se conoce del todo el significado de la salida. Lo siguiente es un intento de interpretarla: 

 $ apt-cache policy exim4-daemon-light
 exim4-daemon-light
  Installed: 4.50-1
  Candidate: 4.50-1
  Package Pin: (not found)
  Version Table:
      4.50-4 555
        500 http://mirror sid/main Packages
  *** 4.50-1 555
        100 /var/lib/dpkg/status
      4.44-2 555
        500 http://mirror sarge/main Packages

La prioridad de cada versión/ubicación es el número a la izquierda. En este caso 500, 100 y 500. El numero a la derecha del número de versión la prioridad actual del paquete.

Notas de Ryan B.

Si te estás preguntando cuales son las opciones del fichero de preferencias del release, basada en este enlace: http://www.debian.org/doc/manuals/repository-howto/repository-howto

Hemos encontrado:

Archive: archivo

Component: componente

Origin: Su empresa

Label: El repositorio Debian de su empresa

Architecture: arquitectura

Así, la línea: "Pin: release a=testing" encontraría valores en el archivo de la versión llamada "testing".

Notas de GeorgiosZarkadas

Me pareció que el uso de un valor superior a 500 a un pin testing/unstable resultaba en apt-get upgrade queriendo actualizar todos los paquetes con una versión mas moderna a testing/unstable, incluso cuando stable tenia un valor pin mas alto que testing/unstable.

Después de consultar el resultado de apt-cache policy <paquete> de alguno de los paquetes que apt-get upgrade consideró que debian ser actualizados, llegué a la conclusión de que si hay múltiples versiones "pinned" a 500 o superior, entonces el "pinning" se considera después del número de versión. Así la versión más alta con el pin mas alto entre todos los paquetes candidatos es selecionada.

Por ejemplo (teniendo stable "pinned" a 700, testing a 650 y unstable a 600): 

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο:      1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Ya que mi objetivo para el uso de distintas fuentes era ser capaz de instalar en ocasiones un paquete de testing o unstable, y no actualizar todos los paquetes, "pinning" testing/unstable a unos valores iguales o superiores a 500 es claramente un método inadecuado para lo indicado anteriormente.

Sin embargo, he encontrado que el uso de un valor inferior a 500 para testing/unstable tiene el efecto deseado. Por ejemplo (testing a 450, unstable a 400 y stable sin pin): 

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο:      1.7.28.3+squeeze1
  Πίνακας Έκδοσης:
     1.7.28.5 0
        450 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        400 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        500 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Notas de Dmitriy Matrosov

Creo que la conclusión de Georgios Zarkada's (de una nota anterior): 

llegué a la conclusión de que si hay múltiples versiones "pinned" a 500 o superior, entonces el "pinning" se considera '''después''' del número de versión.

está equivocada. Vamos a dar un vistazo de nuevo al ejemplo que puso: 

root@freedom:/etc/apt# apt-cache policy deborphan
deborphan:
  Εγκατεστημένα: 1.7.28.3+squeeze1
  Υποψήφιο:      1.7.28.5
  Πίνακας Έκδοσης:
     1.7.28.5 0
        650 http://ftp.gr.debian.org/debian/ wheezy/main amd64 Packages
        600 http://ftp.gr.debian.org/debian/ sid/main amd64 Packages
 *** 1.7.28.3+squeeze1 0
        500 http://ftp.gr.debian.org/debian/ squeeze-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.7.28.3 0
        500 cdrom://[Debian GNU/Linux 6.0.1a _Squeeze_ - Official amd64 DVD Binary-1 20110322-16:05]/ squeeze/main amd64 Packages
        700 http://ftp.gr.debian.org/debian/ squeeze/main amd64 Packages

Primero, apt intenta actualizar desde stable (squeeze/main) ya que stable tiene la prioridad mas alta (700), pero ve que el paquete instalado es más nuevo: 

sgf@shilvana:~$ dpkg --compare-versions 1.7.28.3 lt '1.7.28.3+squeeze1' ; echo $?
0

y 700 de prioridad no es suficiente para volver a una versión anterior. and priority 700 is not enough to downgrade. Entonces, busca una versión candidata, y ahora apt intenta actualizar desde testing (wheezy(main) y ve, que la version de testing es más nueva: 

sgf@shilvana:~$ dpkg --compare-versions '1.7.28.3+squeeze1' lt 1.7.28.5 ; echo $?
0

Y por lo tanto, esta versión (testing) se convierte en candidata.

Por lo tanto, con el fin de actualizar desde stable (como Georgios Zarkadas quiere), debe tener ese paquete con una versión <= de la que se encuentra en stable.

Referencias