Introducción breve a apt-pinning

1 Nota preliminar

En este artículo se explica cómo usar apt-pinning en Debian y distribuciones basadas en Debian (por ejemplo, Ubuntu). apt-pinning permite usar varias versiones de la distribución en un mismo sistema y especificar de qué rama instalar un paquete. Así puedes mantener un sistema principalmente en stable pero instalar paquetes puntuales de testing o unstable (o de repositorios terceros).

Definición breve: apt-pinning = mecanismo para asignar prioridades a paquetes según la rama de origen (release), controlando qué versión será candidata para la instalación.

No garantizo que esto funcione en todos los entornos; prueba primero en un sistema de ensayo.

2 Entorno de ejemplo y objetivo

Ejemplo usado: sistema Debian Lenny (stable). Como ejemplo práctico se explica el caso de phpmyadmin, que al momento de escribir original estaba en tres versiones distintas en stable, testing y unstable:

• lenny (stable): 4:2.11.8.1-5
• squeeze (testing): 4:3.1.2-2
• sid (unstable): 4:3.1.3-1

Objetivo: mantener el sistema con paquetes de stable por defecto, pero permitir instalar phpmyadmin desde testing sin actualizar todo el sistema a testing/unstable.

3 Mi sources.list

Añadí testing y unstable a /etc/apt/sources.list para que el fichero quede como sigue.

vi /etc/apt/sources.list

deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

## Lenny / Stable
deb http://ftp2.de.debian.org/debian/ lenny main
deb-src http://ftp2.de.debian.org/debian/ lenny main

deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main

## Squeeze / Testing
deb http://ftp2.de.debian.org/debian/ squeeze main
deb-src http://ftp2.de.debian.org/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main
deb-src http://security.debian.org/ squeeze/updates main

## Sid / Unstable
deb http://ftp2.de.debian.org/debian/ sid main
deb-src http://ftp2.de.debian.org/debian/ sid main

Abre también /etc/apt/apt.conf y añade la línea para aumentar el límite de caché si necesitas evitar errores de mmap:

vi /etc/apt/apt.conf

APT::Cache-Limit "100000000";

(Sin esto podrías ver el error: E: Dynamic MMap ran out of room)

Luego ejecuta:

apt-get update

4 ¿Por qué controlar prioridades?

Sin apt-pinning apt intentaría instalar siempre la versión más nueva disponible (normalmente desde testing o unstable), lo que puede llevar a mezclar dependencias y terminar con un sistema inestable. Con apt-pinning definimos prioridades (Pin-Priority) para preferir paquetes de stable salvo cuando explícitamente queramos otro origen.

5 Comprobar prioridades actuales

Puedes ver prioridades y orígenes con:

apt-cache policy

Ejemplo de salida (recortada):

server1:~# apt-cache policy  
 Package files:  
  100 /var/lib/dpkg/status  
      release a=now  
  500 http://volatile.debian.org lenny/volatile/main Packages  
      release o=volatile.debian.org,a=stable,l=debian-volatile,c=main  
      origin volatile.debian.org  
  500 http://ftp2.de.debian.org sid/main Packages  
      release o=Debian,a=unstable,l=Debian,c=main  
      origin ftp2.de.debian.org  
  500 http://security.debian.org squeeze/updates/main Packages  
      release v=None,o=Debian,a=testing,l=Debian-Security,c=main  
      origin security.debian.org  
  500 http://ftp2.de.debian.org squeeze/main Packages  
      release o=Debian,a=testing,l=Debian,c=main  
      origin ftp2.de.debian.org  
  500 http://security.debian.org lenny/updates/main Packages  
      release v=5.0,o=Debian,a=stable,l=Debian-Security,c=main  
      origin security.debian.org  
  500 http://ftp2.de.debian.org lenny/main Packages  
      release v=5.0,o=Debian,a=stable,l=Debian,c=main  
      origin ftp2.de.debian.org  
 Pinned packages:  
server1:~#

Como se ve, stable, testing y unstable tienen la misma prioridad (500) en este ejemplo, por eso apt elige la versión más nueva (en este caso phpmyadmin 4:3.1.3-1 desde unstable).

Ver la candidata de un paquete:

apt-cache policy phpmyadmin

Salida de ejemplo:

server1:~# apt-cache policy phpmyadmin  
 phpmyadmin:  
   Installed: (none)  
   Candidate: 4:3.1.3-1  
   Version table:  
     4:3.1.3-1 0  
        500 http://ftp2.de.debian.org sid/main Packages  
     4:3.1.2-2 0  
        500 http://ftp2.de.debian.org squeeze/main Packages  
     4:2.11.8.1-5 0  
        500 http://ftp2.de.debian.org lenny/main Packages  
server1:~#

La línea Candidate indica la versión que apt instalaría.

6 Rango y significado de prioridades

Resumen de las reglas (extraído de man 5 apt_preferences):

• P > 1000: fuerza la instalación incluso si supone un downgrade.
• 990 < P <= 1000: instala la versión aun si no pertenece a la release objetivo (salvo que la instalada sea más reciente).
• 500 < P <= 990: instala la versión a menos que exista una versión de la release objetivo o una versión instalada más reciente.
• 100 < P <= 500: instala la versión a menos que haya una versión de otra distribución o una instalada más reciente.
• 0 < P <= 100: instala la versión solo si no hay versión instalada.
• P < 0: previene que la versión sea instalada.

Caja de referencia rápida:

7 Ejemplo práctico de archivo de preferencias (apt-pinning)

Puedes crear /etc/apt/preferences o un fichero dentro de /etc/apt/preferences.d/ con prioridades. Ejemplo genérico:

Package: *
Pin: release a=stable
Pin-Priority: 700

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

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

Si quieres forzar que phpmyadmin provenga de testing preferentemente:

Package: phpmyadmin
Pin: release a=testing
Pin-Priority: 990

Después de editar las preferencias, actualiza cachés y comprueba la candidata:

apt-get update
apt-cache policy phpmyadmin

Para instalar una versión concreta puedes usar:

apt-get install phpmyadmin=4:3.1.2-2

O usar la opción -t para elegir una release objetivo (con precaución):

apt-get -t testing install paquete

8 Buenas prácticas y medidas de seguridad

• Prueba siempre en un entorno no productivo antes de aplicar cambios en producción.
• Documenta cualquier pin y guarda copias de /etc/apt/sources.list y /etc/apt/preferences.d/*.
• Evita pins amplios que afecten a Package: * salvo que entiendas el impacto global.
• Usa Pin-Priority conservadoras (por ejemplo stable 700, testing 600) y sube la prioridad solo para paquetes concretos.
• Si dependencias complejas se actualizan, revisa manualmente las dependencias y realiza pruebas de regresión.

9 Alternativas y cuándo no usar apt-pinning

Alternativas a apt-pinning:

• Contenerizar aplicaciones (Docker) para aislar versiones y dependencias.
• Usar backports oficiales o repositorios PPA con paquetes reempaquetados para la rama estable.
• Compilar localmente el paquete o usar paquetes estáticos (cuando sea seguro).

Cuándo no usar apt-pinning:

• Si necesitas coherencia total entre paquetes (por ejemplo clusters críticos), mezclar ramas puede introducir incompatibilidades.
• Si no puedes probar dependencias y actualizaciones de forma controlada.

10 Fallos comunes y cómo mitigarlos

• Error: resolver dependencias rotas tras instalar un paquete desde unstable. Mitigación: revertir usando apt-get install paquete=versión_estable o restaurar desde backup y rehacer pin con prioridad más baja.
• Error: actualización inadvertida de muchas librerías. Mitigación: evitar pins globales y usar pins por paquete.
• Error: apt-cache size o mmap. Mitigación: aumentar APT::Cache-Limit como se mostró.

11 Lista de comprobación por rol

Administrador de sistemas:

• Probar en staging.
• Documentar /etc/apt/sources.list y preferencias.
• Revisar dependencias antes de aplicar.

Desarrollador:

• Preferir contenedores si solo necesitas una versión distinta para desarrollo.
• Si pides un pin, especifica el paquete y la versión exacta.

Operaciones de producción:

• Programar ventanas de mantenimiento para cambios de pin.
• Mantener backup y plan de rollback.

12 Pequeña metodología para introducir apt-pinning

1. Evaluar necesidad: ¿por qué se necesita una versión fuera de stable?
2. Identificar paquetes concretos y dependencias.
3. Crear fichero en /etc/apt/preferences.d/ con pins por paquete.
4. Probar en entorno controlado y ejecutar suites de tests.
5. Documentar e implementar en producción durante ventana de mantenimiento.

13 Resumen final

apt-pinning es una herramienta útil para mezclar ramas de Debian con control fino sobre el origen de paquetes. Úsalo con precaución: limita pins a paquetes específicos, prueba en entornos controlados y documenta los cambios. Para aislamiento máximo, considera alternativas como contenedores o backports.

Notas importantes:

• No inventes versiones ni dependencias; verifica siempre con apt-cache policy.
• Guarda configuraciones y realiza respaldos antes de cambios en producción.

Критерии приёмки

• El paquete deseado se instala desde la release especificada y apt-cache policy muestra la Pin-Priority esperada.
• No se rompe la resolución de dependencias tras la instalación.

Glosario (una línea cada término):

• apt-pinning: asignación de prioridades a paquetes según su release de origen.
• release: etiqueta que identifica una rama de Debian (stable, testing, unstable).
• Pin-Priority: valor numérico que determina qué versión prefiere apt.

Fin del artículo.