Cómo resolver un conflicto de dependencias en Fedora y no morir en el intento (y cómo evitarlos).

Foro para discutir sobre la documentación en linux (libros, ebooks, documentos, editoriales, autores, etc), así como temas publicados en el sitio.
Responder
Avatar de Usuario
Fedoriano
Forista Medio
Forista Medio
Mensajes: 108
Registrado: Sab Jul 21, 2012 12:12 am

Cómo resolver un conflicto de dependencias en Fedora y no morir en el intento (y cómo evitarlos).

Mensaje por Fedoriano » Sab Oct 13, 2012 6:10 pm

Hola. Llevaba tiempo sin escribir un manual sobre Fedora, pero estaba ocupado con otras cosas y no tenía muchas ganas. El caso es que esta parte tenía ganas de escribirla hace tiempo. ¿Qué hay que hacer cuando tenemos dos repositorios que se llevan mal con paquetes igualmente conflictivos? Uno puede tomar la amarga decisión de reinstalar, borrar un montón de paquetes para resolver el conflicto y luego reinstalar, puede ir a llorarle a su mamá http://foro.desdelinux.net/viewtopic.php?id=716 , o seguir este manual y resolver sus problemas. :)

Bien, el conflicto de paquetes que más comúnmente se da en Fedora es entre los paquetes de rpmfusion y ATrpms. Hay gente que necesita este último repositorio porque, entre otras cosas, es el que contiene Cinelerra. Aunque en el caso anterior vemos que sucede con un repositorio que contiene Unity.

El caso, es que, salvando este caso y algunos otros más, los repositorios de Fedora se suelen llevar bien entre ellos, pero cuando no es así, tenemos problemas.

Para resolver un conflicto entre paquetes, recomiendo seguir estos pasos:

Nota: Necesitamos estar en modo superusuario para todo lo que hagamos en esta guía.

Paso 1: Deshabilitar uno de los repositorios conflictivos, en los casos anteriores, ATrpms o el repo de Unity. Para ello nos dirigiremos con privilegios de superusuario al directorio /etc/yum.repos.d , y editamos el archivo correspondiente a nuestro repositorio, poniendo en la línea que dice "enabled=1", un 0 donde está el 1. Si lo hacemos mediante consola, es así:

Código: Seleccionar todo

su
cd /etc/yum.repos.d
nano nombrerepo.repo
Esto es lo que nos sale en atrpms:

Código: Seleccionar todo

[atrpms]
name=Fedora $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
enabled=1
gpgcheck=1
Y así tiene que quedar:

Código: Seleccionar todo

[atrpms]
name=Fedora $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
enabled=0
gpgcheck=1
Guardamos con Ctrl+O seguido de un enter, y a lo mejor convendría no salirnos de la terminal, ya que quizás queramos después volver a activar el repositorio.

Nota: Si queremos conservar después el repositorio, este paso nos lo podemos saltar, ya que hay una manera de hacerlo directamente junto al paso 2, pero a lo mejor queremos desactivar el repositorio definitivamente, y el método anterior es la forma de hacerlo.

Paso 2: Ejecutar yum distro-sync. Esta es una de las herramientas más potentes de YUM, que sincroniza los paquetes llevándolos a la última versión de los repos que tengamos disponibles, siendo capaz de actualizar, desactualizar y sustituir (no siempre) paquetes.

Código: Seleccionar todo

yum distro-sync
O bien si nos hemos saltado el paso 1:

Código: Seleccionar todo

yum --disablerepo=nombredelrepositorio distro-sync
Una vez terminado el paso 2, puede que yum haya realizado su labor correctamente, y por tanto el conflicto de paquetes ya se haya resuelto. Sin embargo, por el hecho de que es posible que los repositorios hayan sustituido unos paquetes por otros, es probable que devuelva un mensaje de error, indicando los conflictos que ha encontrado.

Si se da lo segundo, es el momento de pasar al paso 3.

Paso 3: Identificar y eliminar los paquetes conflictivos.

Si yum distro-sync encuentra un conflicto de paquetes, nos mostrará un error de este tipo:

Código: Seleccionar todo

Error: Paquete: elquesea.fc17.i686 (@updates/17)
           Necesita: otropaquete >= 2
           Eliminando: otropaquete-2.fc17.i686 (@updates/17)
               otropaquete = 2.fc17
           Desactualizado por: otropaquete-1.fc17.i686 (updates)
               otropaquete = 1.fc17
           Disponible: ***
               ***
           Disponible: ***
               ***
En este caso deberemos eliminar el paquete "otropaquete" sin afectar a los paquetes que dependen de él, después, yum distro-sync arreglará las dependencias

Para eliminar el paquete "otropaquete" y todos los que sean como él:

Código: Seleccionar todo

rpm -e --nodeps otropaquete-2.fc17.i686
Y así con todos los paquetes conflictivos.

Aunque la verdad es que no sé si el anterior error es el más común en un conflicto de dependencias, lo que parece es que no puede encontrar el paquete que sustituye a los que va a quitar, en cualquier caso, la solución si aparece es la que he comentado.

El error que seguro que puede aparecer es este:

Código: Seleccionar todo

el archivo ejemplo de la instalación de unpaquete.x86_64 entra en conflicto con el archivo del paquete otropaquete.i586
En este caso, deberemos eliminar de la misma forma el paquete "otropaquete", para ello se procede de la misma manera que anteriormente:

Código: Seleccionar todo

rpm -e --nodeps otropaquete.i586
Una vez terminamos de eliminar los paquetes conflictivos, pasamos al paso 4.

Paso 4: Volver a ejecutar yum distro-sync

Código: Seleccionar todo

yum distro-sync
o si nos hemos saltado el paso 1:

Código: Seleccionar todo

yum --disablerepo=nombredelrepositorio distro-sync
Y así, YUM deberá haber resuelto el conflicto de paquetes, y Fedora se podrá actualizar con normalidad.


...


¿Y qué hay que hacer si queremos tener habilitado el repositorio conflictivo?

Para eso tendremos que instalar y configurar el plugin priorities de YUM.

Paso 1: Instalar el plugin priorities:

Código: Seleccionar todo

yum install yum-plugin-priorities
El plugin priorities sirve para asignar una prioridad a cada repositorio, de manera que si tenemos un paquete 1 instalado en un repo 1 y existe una versión actualizada del mismo en un repo 2, pero el repo 1 tiene una prioridad mayor que el repo 2, el paquete 1 no se actualizará.

Paso 2: Configurar los repositorios:

El plugin priorities asigna por defecto una prioridad de 99 a cada repositorio. Para modificar la prioridad nos vamos a la carpeta que contiene nuestros repositorios, /etc/yum.repos.d

Código: Seleccionar todo

cd /etc/yum.repos.d/
y abrimos los archivos de nuestros diferentes repositorios, modificando su prioridad según convenga. Podemos listar los archivos de un directorio con el comando ls .

Abrimos los archivos de repositorio con nuestro editor de texto favorito, por ejemplo, nano:

Código: Seleccionar todo

nano repositorio.repo
Para modificar la prioridad de un repositorio, añadiremos la linea "priority=XX" al final de las secciones que nos interese de cada repositorio, siendo XX la prioridad que le asignemos, la cual puede ser entre 1 y 99. De manera que quede así (con el repo ATrpms, pero igual de válido para los demás):

Código: Seleccionar todo

[atrpms]
name=Fedora $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/f$releasever-$basearch/atrpms/stable
gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
enabled=1
gpgcheck=1
priority=XX
Yo recomiendo poner una prioridad de 50 para los repositorios fedora, updates, y todos los repositorios que se lleven bien con estos dos y entre sí, y al resto una prioridad mayor o menos que 50, según convenga.

Activamos el repositorio si no estaba activado (es mejor no activar los source y debug) y guardamos con Ctrl+O seguido de Enter.

Y ya está. Espero que este manual sea de utilidad a quien tenga este tipo de problemas.

Un saludo. :)
Avatar de Usuario
Yoyo
Administrador
Administrador
Mensajes: 3125
Registrado: Mar Jun 06, 2006 7:00 am
Ubicación: España
Contactar:

Re: Cómo resolver un conflicto de dependencias en Fedora y no morir en el intento (y cómo evitarlos).

Mensaje por Yoyo » Sab Oct 13, 2012 8:15 pm

Excelente tip, de los que hacen historia, ya lo tienes en portada ;)

Un saludo.
Responder
  • Similar Topics
    Respuestas
    Vistas
    Último mensaje