Apt-pinneando el iceweasel de unstable

Me cabrea mucho cuando un paquete que uso no se actualiza porque tiene algunas dependencias "raras"1 sin mantenedor que lo bloquean. Y es lo que está pasando actualmente con el paquete iceweasel en testing. Así que hace unos meses, cuando la antigüedad de la versión 17 hacía que me fallara en varias webs, me lié la manta a la cabeza y me instalé la versión de experimental. Que es la que he estado usando hasta esta mañana, cuando al actualizarme de la 25~b3 a la 25~b9 me ha empezado a fallar alguna de las páginas que visito habitualmente (es lo que tiene usar experimental, claro: eres una cobaya).

Así que, aprovechando que en unstable ya tienen una versión reciente (de hecho, la 24, que es la actual estable), he hecho downgrade a ella. Pero para ello, primero hay que tener ambos repos testing y unstable a la vez pero sin que el sistema salte de testing a unstable (cosa que no queremos). Y para eso es para lo que existe el apt pinning.

Este es el fichero /etc/apt/preferences que he creado en mi caso:

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

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

La prioridad en este caso es proporcional al número: mayor valor implica más prioridad (esto lo aclaro porque es muy habitual ver prioridades mayores con números menores, como la prioridad de los procesos en Unix). Y lo que quiere decir es que las versiones de testing tienen más prioridad que las de unstable y por lo tanto se eligen sobre estas.

"Pues entonces no has hecho nada", me diréis. Sí y no. Es cierto que si ahora hago un aptitude update && aptitude upgrade no me actualiza ningún paquete (si lo hace, es que he hecho algo mal), pero es que era eso lo que queríamos: no saltar a unstable. Para instalar un paquete concreto de unstable (y sus dependencias), se lo debemos indicar a aptitude o apt-get mediante un target:

aptitude -t unstable install iceweasel

Ahora, a pesar de que unstable tiene menos prioridad que testing, nos instalará la versión allí presente.

Antes de hacer este tipo de cosas, no está de más echar un vistazo a cómo están actualmente las prioridades. Esto se consigue con apt-cache policy, por ejemplo:

$ apt-cache policy iceweasel
iceweasel:
  Instalados: 24.0-2
  Candidato:  24.0-2
  Tabla de versión:
 *** 24.0-2 0
        100 http://ftp.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     17.0.9esr-1~deb7u1 0
        600 http://ftp.debian.org/debian/ jessie/main amd64 Packages

Podemos también usar aptitude, aunque requiere de un poco de regex-fu adicional:

$ aptitude versions "^iceweasel$" 
Package iceweasel:
p A 17.0.9esr-1~deb7u1                            testing                   600 
i A 24.0-2                                        unstable                  100

Con cualquiera de ambas podemos ver que es la versión de unstable la que ahora está instalada a pesar de su menor prioridad.

El pequeño inconveniente es que aptitude upgrade no va a actualizar la versión de unstable, sino la de testing, así que hay que hacer manualmente un aptitude -t unstable install iceweasel de vez en cuando, para mantenerlo actualizado2.

Naturalmente el apt-pinning no sirve sólo para este caso. Podemos usarlo para instalar paquetes de unstable o testing en stable, para instalar paquetes de distintos repos extra o de otras distros sin actualizar lo que no queremos, etc. Es una herramienta avanzada, y aunque por supuesto mezclar repositorios siempre conlleva riesgos, usándola correctamente podemos tenerlo bajo control la mayoría de esos riesgos.

Aunque recordad: un gran poder conlleva siempre una gran responsabilidad.

:wq


  1. si hay problemas con una dependencia esencial del paquete es lógico que esté bloqueado 

  2. sé lo que me váis a decir, y no, no pienso apt-pinnear el paquete porque lo que quiero es que entre de una maldita vez en testing

blogroll

social