Jump to content

(Debian) Apt-Pinning. Obteniendo paquetes de diferentes ramas/repositorios


Recommended Posts

X12mt4N.png

 

En ocasiones ocurre que, por una razón u otra nos vemos utilizando ramas diferentes para el mismo Debian o repositorios externos para ciertos paquetes y no es nada fácil a la hora de mantenerlos actualizados o mantener a raya los problemas de dependencias.

Para estos casos existe lo que se conoce como AptPreferences o también Apt-pinning.
Mediante un proceso de configuración bastante sencillo podemos utilizar, instalar y mantener actualizados paquetes de diferentes repositorios sin preocuparnos por dependencias ni por tener que actualizar cada paquete manualmente.

El archivo donde configuraremos el Pinning es /etc/apt/preferences, que en condiciones normales lo encontraremos vacío.

La estructura para definir los paquetes que queremos instalar de cada rama es siempre la misma:
 

Package:
Pin:
Pin-Priority:

Package: = Aquí indicaremos la lista de paquetes a instalar.

Ejemplos:



Package: =iceweasel*

Con esto indicamos que el paquete que queremos instalar es iceweasel. Notar que he añadido un comodín al final *, de esta manera indico que cualquier paquete cuyo nombre empiece por "iceweasel" debe ser considerado, de esta manera no sólo será considerado iceweasel, sino iceweasel-l10n-es-es, iceweasel-l10n-de ...
 

Package: = *

En esta ocasión he usado únicamente el comodín *, por lo que le estaría pidiendo cualquier paquete de repositorios (Esto viene bien si lo combinamos luego con la prioridad)




Pin: = Aquí indicamos la rama, versión o repositorio desde el que queremos instalar los paquetes

Ejemplos:
 

Pin: release a= testing

con release a= podemos indicar la rama de los repositorios que queremos utilizar
 

Pin: release n= wheezy

con release n= podemos indicar el nombre de la versión de Debian que queremos utilizar
 

Pin: version = X.Y*

Con esto estamos indicando que queremos una versión concreta X.Y del paquete/s indicado/s

 

Pin: version = 2.8*

Pin:  version = 10.2*

 




Pin-Priority: aquí indicamos la prioridad que tendrán esos paquetes que hemos indicado a la hora de actualizarlos

La prioridad se define de la siguiente manera
  • Prioridad > 1000: Se fuerza la instalación de paquetes, aunque estén en versiones inferiores a las de otros repositorios o a las ya instaladas.
  • 990 << Prioridad <= 1000: Se instalará el paquete salvo que la versión ya instalada sea más reciente, aunque dicho paquete no provenga de la rama principal.
  • 500 << Prioridad <= 990: Se instalará el paquete siempre que la versión instalada sea más antigua y no exista una versión más reciente en la rama principal.
  • 100 << Prioridad <= 550: Se instalará el paquete siempre que la versión instalada sea más antigua y no exista una versión más reciente en cualquiera de los repositorios incluidos en el sources.list
  • 0 << Prioridad <= 100: Ese paquete sólo se instala si no hay ninguna versión ya instalada del mismo
  • Prioridad << 0: Ese paquete no será instalado bajo ninguna circunstancia

Los rangos son bastante amplios para que, en caso de colocar distintos repositorios dentro del mismo rango, podamos establecer mayor o menor prioridad entre ellos. En estos casos, el número más alto indicará mayor prioridad y viceversa.


Ejemplos:
 

Pin-Priority: 900

Es inferior a 990 y superior a 500, por lo que estamos en el caso 2º, Se instalará el paquete salvo que la versión ya instalada sea más reciente.
 

Pin-Priority: 700

Volvemos a estar en el caso 2º, pero el número es inferior a 900, por lo que Se instalará el paquete salvo que la versión ya instalada sea más reciente, pero el repo marcado como 900 tendrá mayor prioridad.
 

Pin-Priority: -10

La prioridad es negativa, por lo que estamos evitando la instalación/actualización de este paquete, pase lo que pase. Nota recordemos que estamos indicando una rama/repositorio concreto con el Pin:, por lo que la prioridad afecta sólo al repositorio con el que estamos trabajando. Si el paquete "bloqueado" existe en otro repositorio, no estará bloqueado, sólo en este.





Apt.conf

Este archivo no suele ser necesario modificarlo, pero en algunos casos sí es necesario/recomendable.

El apt-conf nos permite, entre otras cosas definir cuál será la rama principal de nuestros repositorios y aunque normalmente estará en blanco, su apariencia será más o menos así:
 

APT::Default-Release “testing”;
APT::Cache-Limit 30000000;
Apt::Get::Purge;
APT::Clean-Installed;
APT::Get::Fix-Broken;
APT::Get::Fix-Missing;
APT::Get::Show-Upgraded “true”;

Como podemos ver, con el APT::Default-Release definiremos la rama pricipal de nuestro sistema
Con el APT::Cache-Limit podemos limitar el caché que vamos a utilizar en el proceso de actualización de lista de paquetes. No debería ser necesario tocar este valor, pero en el caso de que, por haber añadido muchos repositorios nos encontremos con un error de "cache insuficiente", sólo tenemos que aumentar un poco este valor.




Puntualización La explicación se ha centrado en Debian por el uso que hace esta distribución de las diferentes ramas de desarrollo y el juego que da la combinación de las mismas, pero como han de suponer, el Apt_Pinning también puede ser configurado en todas las distribuciones basadas en Debian, como Linux Mint, LMDE o Trisquel.

En el caso de las derivadas habrá que tener en cuanta cada caso y cómo administran sus repositorios, versiones, ramas y demás, pero básicamente hablaríamos del mismo procedimiento para cualquier derivada de Debian.
Link to post
Share on other sites
  • 2 months later...

El /etc/apt/preferences, como su nombre indica, te permite establecer tus preferencias a la hora de descargar paquetes :P.

 

Todo depende de la configuración que elijas, como dice arriba, según el valor asignado puedes ir desde no instalar nunca un paquete hasta forzar su instalación a toda costa, que el pquete provenga de un repositorio y no de otro, etc.

 

 

En el caso concreto de Iceweasel, Aunque el equipo de Mozilla Debian forkea todas las versiones de Firefox, a las ramas más estables unicamente suelen llegar las versiones con soporte extendido (ESR) y no las intermedias. Éstas aparecen en la rama "experimental".

El sistema por defecto utilizará siempre las ramas más estables a la hora de instalar paquetes, por lo que al hacer un "aptitude install iceweasel", aunque tengas la rama experimental en repositorios, el paquete que se va a instalar es el de alguna de las ramas inferiores, stable, Testing o la que estés usando.

 

Para instalar paquetes de otras ramas se puede recurrir a la opción -t, en este caso "aptitude install -t experimental iceweasel", con eso indicaríamos al sistema la rama/repositorio concreta de la que queremos que instale el paquete. Para instalar un paquete individual o sólo una vez, esta opción es sencilla, pero sabemos que iceweasel se va a estar actualizando al menos 1 vez cada 6 semanas, por lo que en lugar de instalarlo especificando manualmente la ramas, establecemos en las preferencias que todo lo relacionado con iceweasel lo instale siempre desde experimental, sin tener en cuenta las versiones presentes en otras ramas, porque en este caso concreto lo que buscamos es centrarnos en la versión más alta, no en las versiones ESR que son las que el sistema instalaría/actualizaría por defecto.

 

 

Por decirlo de una manera más sencilla, es una forma de automatizar el proceso.

Link to post
Share on other sites
  • 3 months later...

Una duda que tengo, más que nada para curarme en salud, esta sería una buen configuración para añadir unstable al sources.list?

 

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

 

 

Edito:

bueno, de paso también pregunto, si es aconsejable añadir unstable, o si es mejor descargar los deb que necesite desde debian, por si puede traer problemas a la larga

 

Gracias de antemano, un saludo

Edited by southside54
Link to post
Share on other sites

Depende del efecto que quieras conseguir. Las prioridades entre 100 y 0 indican que el paquete NO será instalado si ya existe otra versión del mismo instalada desde otro repositorio/rama.

Sería válido para paquetes sin instalar y una única vez.

El inconveniente que puede haber es que, como no hay ningún paquete indicado (*) afectará a todos por igual.

 

Si es para algo concreto, que deba mantenerse actualizado desde testing sería más productivo indicar los paquetes más relevantes de esa aplicación y ponerle una prioridad entre 990 y 100 y, al mismo tiempo, poner una prioridad ligeramente inferior para todos los demás paquetes de la rama principal

Link to post
Share on other sites
  • 2 weeks later...

entiendo bien la idea, y yo me he montando lo mio en mi cabeza, pero no se como lo tendria que hacer.

por lo que leo, esto me serviria para mantener el kernel  actualizado?

osea, con testing andamos 3.0.2. 

podria configurarlo para que me actualizase los paquetes de kernel_image....etc de la rama unstable por ejemplo?

salu2 y gracias

PD: acabo de instalar debian 7 con kde, y estoy supercontento, en otro portatil tengo problemas para que me coja la NAT broadcom

Link to post
Share on other sites

me interesa actualizar el kernel a la version mas reciente, y por que no... en megaia tengo kde 4.10 y me va de miedo igual que la 4.8 que trae debian. por  lo que tambien me gustaria actualizar KDE.

he utilizado las siguientes lineas dentro de "apt/preferences" con resultado negativo:

 

ackage:=kernel*
Pin:=release a=experimental
Pin-Priority:900
 
Package:=KDE*
Pin:=release a=experimental
Pin-Priority:900
 
cuando hago "aptitude update" me dicen lo siguiente:
 
W: No se entiende el pin tipo =release
W: No se entiende el pin tipo =release
 
entiendo que la lineas "Pin:=release a=experimental" no es experimental lo que tengo que poner.
ayuda porfavor? y tambien decirme si es una locura o no lo que estoy haciendo, no me quiero cargar debian.
Link to post
Share on other sites

En "Package" va la lista de paquetes. Una entrada para cada paquete individual con prioridades iguales es una locura :P (Aparte de tener un "=" de más)

Los paquetes kernel* y KDE* no existen en repositorios, así que no podrá encontrarlos.

Si apuntas a la rama experimental en /etc/apt/preferences, ten en cuenta de meterlos también en tu sources.list

Package: linux-image-3* kde* libkde* phonon* libkio* libkpart* libkpty* 
Pin: release a=experimental
Pin-Priority: 900

Así con todos los paquetes involucrados.

 

Locura, dependerá de lo que hagas a partir de aquí :P

Link to post
Share on other sites

En "Package" va la lista de paquetes. Una entrada para cada paquete individual con prioridades iguales es una locura :P (Aparte de tener un "=" de más)

Los paquetes kernel* y KDE* no existen en repositorios, así que no podrá encontrarlos.

Si apuntas a la rama experimental en /etc/apt/preferences, ten en cuenta de meterlos también en tu sources.list

Package: linux-image-3* kde* libkde* phonon* libkio* libkpart* libkpty* 
Pin: release a=experimental
Pin-Priority: 900

Así con todos los paquetes involucrados.

 

Locura, dependerá de lo que hagas a partir de aquí :P

en el source.list tengo que meter tambien la rama experimental?

y cuando dices que lo de la locura dependera de lo que haga apartir de ahora....??? 

me da un poco de miedo, yo solo quiero tener sobretodo el kernel actualizado, ya que tengo un dichoso portatil sandybrige con tecnologia optimus de nvidia...y la tengo que tener desactivada para que no consuma...y siempre me gusta tener el kernel lo mas actualizado posible.

 

antes compilaba, gracias a tu magnifico tutorial. pero siempre me dejo algo fuera, o tengo algun error nuevo y desconocido que solo a mi me pasa...jajaja

pero si me dices que es una locura, prefiero volver a intentar compilar el kernel por mi mismo.

un saludo y gracias

Link to post
Share on other sites

Hay 50000 paquetes y 5 ramas distintas, será locura o no en función de las combinaciones que pretendas a hacer, que a priori no las sé, por eso no puedo decir si sí o si no.

 

Para instalar el último linux estable, ahora mismo habría que pillarlo desde unstable:

echo 'deb http://ftp.fr.debian.org/debian/ unstable main contrib non-free' >> /etc/apt/sources.list.d/unstable.list
aptitude update
aptitude install -t unstable linux-image-3.9-1-amd64

o

aptitude install linux-image-3.9-1-686-pae

Que debería entrar en nada a testing, pero mientras tanto el apt-pinning:

Package: *
Pin: release a=testing
Pin-Priority: 750
 
Package: linux-*-3.9*
Pin: release a=unstable
Pin-Priority: 900
Edited by Shiba87
ups
Link to post
Share on other sites
  • 2 months later...

Buenas, de nuevo por este hilo xD

 

Ahora mismo estoy en debian estable (por lo menos hasta que termine de entrar gnome 3.8 en testing), y si he entendido bien lo de las prioridades, con esta configuración obtendría actualizaciones automáticas desde wheezy-backports?

Package: *
Pin: release n=wheezy-backports
Pin-Priority: 995

También tengo la duda si debería poner "Pin: release n=wheezy-backports" o "Pin: release a=wheezy-backports"

 

Un saludo

Edited by southside54
Link to post
Share on other sites
  • 11 months later...

Bueno, ultimamente estoy probando diferentes distros debian, desde la testing, solydX, etc...

buscando la manera de correr cinnamon correctamente al igual que linux mint, todo esto es xq LMDE esta algo estancado y con un futuro incierto, y mint no me gusta al estar basado en ubuntu, debatiendo si la proxima version la basaran en debian estable o seguiran con testing. os invito a todos a pasar por el foro de LMDE y votar. yo he votado por la rama testing, pero todo apunta a que pasaran a estable y basaran LMDE en una distro "best stable"!!! xD

bueno, me lio, el caso es que ultimamente estoy jugando mucho con los repositorios, con apt pinning, buscando mi combinacion perfecta para instalar cinnamon sin empezar a romper el sistema, y como siempre acabo por estos foros. queria compartir tambien paginas que me han servido de guia y referencia, para entender un poco mas apt-pinning y sus preferencias.

 

1º: en primer lugar, un tema que creo que todos deberiamos de leer, antes de ponernos a mezclar repositorios

http://www.esdebian.org/wiki/sistemas-mixtos

 

2ºestructura y explicacion de como funcionan los repositorios y las ramas de debian:

http://www.esdebian.org/wiki/introduccion-repositorios-debian

 

no es gran cosa, pero los proximas dias si tengo que volver a instalar y empezar de nuevo, ya tengo toda la informacion aqui, y no tengo que buscar por mas sitios.

un saludo

 

PD: actualmente tengo debian testing, con repos SID, y cinnamon instalado y funcionando...aun no me lo creo...a ver cuanto tiempo tarda en romperse...xD

Link to post
Share on other sites

por cierto, como veis esto:

mi source.list

 

#TESTING
deb http://ftp.es.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.es.debian.org/debian/ testing main contrib non-free
## Actualizaciones de seguridad
deb http://security.debian.org/ testing/updates main contrib non-free
deb-src http://security.debian.org/ testing/updates main contrib non-free
#SID
deb http://ftp.es.debian.org/debian/ sid main contrib non-free
deb-src http://ftp.es.debian.org/debian/ sid main contrib non-free
 
 
mis preferencias de apt-pinning
Package: *
Pin: release a=testing
Pin-Priority: 850
 
Package: *
Pin: release n=sid
Pin-Priority: 800
 
 
obviamente como podeis ver, o es mi intencion. quiero que prevalezca testing, y no quiero pasar mas alla del testing. sid solo lo he usado para instalar cinnamon y todo lo que este tuvo que actualizar para instalar cinnamon.
este debian con esta configuracion lo acabo de poner en el ordenador del trabajo, y tambien en casa.
ni que decir, que en el trabjao lo que necesito es estabilidad. de momento cinnamon marcha correcto, quiero seguir recibiendo actualizaciones de testing y no de sid que me puedan petar.
es correcto? recomendais alguna otra configuracion?
Link to post
Share on other sites

A mí los mirrors españoles me dan grima :lol:

De resto... sea como sea sigue siendo peliagudo, así que será lo que tenga que ser :sweat:

Ya, por eso tengo mint tal cual, para trabajar. Pero es que estoy tan acostumbrado a cinnamon que no se usar otro entorno. Y hay ciertos programas del trabajo que necesito que solo están para debían y he probado diferente distros pero ninguna con cinmamon e intentarlo instalar es una pesadilla...

Tendré que desistir y usar Mint original

Link to post
Share on other sites

El mayor problema es que últimamente cinnamon está sufriendo muchos cambios y al ritmo que se mueve Debian les es imposible seguirlos (Si cinnarch no pudo...), no hacen más que entrar y salir continuamente versiones a sid, no llegan a bajar a Testing :muro:

En el momento que se estabilice será más sencillo, pero mientras... toca ir a la aventura como un pingüino valiente :jojojo:

Link to post
Share on other sites
  • 2 years later...

No me aclaro con el Apt-Pinning, a ver yo tengo estos repositorios instalados:

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

deb http://security.debian.org/debian-security/ testing/updates non-free contrib main 

# Numix
deb http://ppa.launchpad.net/numix/ppa/ubuntu/ yakkety main 

# Kali linux
deb http://http.kali.org/kali/ kali-rolling main contrib non-free 

El caso es que los de Kali solo los quiero para ciertos programas y que use las veriones de testing por defecto también me gustaría tener las últimas versiones de firefox y no la ESR, he dejado el /etc/apt/apt.conf así:

APT::Default-Release testing;

Y el archivo /etc/apt/preferences de esta forma:

Package:firefox*
Pin:release a=unstable
Pin-Priority:990

¿Por qué no funciona?

 

EDITADO

 

No se como he llegado a esto, pero ahora tengo un bonito Kali Linux/Debian :icon_ouch: aunque no me falló nada, solo actualizó unas cuantas cosas a Kali...

Edited by mijailbellum
Link to post
Share on other sites

Tienes que tener en cuenta que la rama/repositorio esté especificado, de lo contrario no lo va a tener en cuenta.

En tu sources.list no hay nada que apunte a unstable, no tienes la lista de paquetes de esa rama y, por tanto, no lo tiene en cuenta y pasa a la siguiente opción, que es Testing.
 
 

# Testing
deb http://ftp.es.debian.org/debian/ testing contrib non-free main
 
# Unstable
deb http://ftp.es.debian.org/debian/ unstable contrib non-free main

deb http://security.debian.org/debian-security/ testing/updates non-free contrib main

# Numix
deb http://ppa.launchpad.net/numix/ppa/ubuntu/ yakkety main

# Kali linux
deb http://http.kali.org/kali/ kali-rolling main contrib non-free


 
Y las prioridades bien claras
 

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

Package:=firefox*
Pin: release a=unstable
Pin-Priority:900



Con Kali no he entendido si hay que instalarlos preferentemente o no, así que me curaré en salud :P
 

Package:=*
Pin: release a=kali-rolling
Pin-Priority:500



Así tendrías testing por defecto, para cualquier paquete, unstable con mayor prioridad sólo para paquetes de firefox y Kali con la mínima prioridad, para paquetes de los que no existan versiones nuevas en los demás repositorios

Edited by Shiba87
dedazo
Link to post
Share on other sites
  • 3 weeks later...

Por cierto con la liada de Kali, ahora mi sistema se cree que es Kali Roling y no veo la forma de decirle que es Debian Testing, he modificado los archivos /etc/issue /etc/debian_version y /etc/lsb-release especificando esto, pero en los detalles de la configuración me sigue diciendo que estoy en kali... ¿Quién determina la distribución del sistema?

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...