Algunos paquetes del repositorio Gentoo no tienen contenido real pero son utilizados para instalar un conjunto de paquetes. Por ejemplo, el paquete kde-apps/kde-metainstalará un entorno KDE completo en su sistema incluyendo varios paquetes relacionados con KDE y también sus dependencias.
Si quiere desinstalar dicho paquete de su sistema, ejecutando emerge --unmerge sobre el paquete no tendrá efecto total ya que las dependencias permanecerán en su sistema.
Portage tiene la funcionalidad de eliminar las dependencias huérfanas, pero la disponibilidad de software necesita que primero actualice completamente su sistema, incluyendo los nuevos cambios que ha aplicado si actualizó los ajustes USE.
Después de esto, puede ejecutar emerge --depclean para eliminar las dependencias huérfanas. Cuando haya terminado, podría ser necesario reconstruir las aplicaciones que estuvieran enlazadas dinámicamente a las que acaban de ser eliminadas, a pesar de que recientemente se ha añadido a Portage soporte para este asunto.
Todo esto se lleva a cabo a través de tres órdenes:
revdep-rebuild es parte del paquete app-portage/gentoolkit; no olvide instalarlo primero:
Por defecto Portage permite todas las licencias, excepto Acuerdos de Licencia de Usuario Final (End User License Agreements o EULAs) que requieren la lectura y firma de un acuerdo de aceptación.
La variable que controla las licencias permitidas es ACCEPT_LICENSE, la cual se puede ajustar en el archivo /etc/portage/make.conf. En el siguiente ejemplo, se muestra este valor por defecto:
ARCHIVO
/etc/portage/make.conf
Valor por defecto de ACCEPT_LICENSECon esta configuración, los paquetes que requieren interacción durante la instalación para aprobar su EULA no se podrán instalar. Los paquetes sin una EULA se podrán instalar.ACCEPT_LICENSE="* -@EULA"
Puede ajustar ACCEPT_LICENSE globalmente en /etc/portage/make.conf, o puede especificarlo en de forma que afecte a solo un paquete en /etc/portage/package.license.
Por ejemplo, si quiere permitir la licencia google-chrome para usar el paquete www-client/google-chrome, añada lo siguiente a /etc/portage/package.license:
ARCHIVO
/etc/portage/package.license
Aceptar la licencia google-chrome para el paquete google-chrome>=www-client/google-chrome-55.0.2883.87 google-chrome
Esto permite la instalación de versiones de google-chrome mayores o iguales a la 55.0.2883.87 pero no si son inferiores.
Importante.
Las licencias se almacenan en el directorio /usr/portage/licenses/, y los grupos de licencias se guardan en el archivo /usr/portage/profiles/license_groups. La primera entrada de cada línea en letras MAYÚSCULAS, es el nombre del grupo de licencias, y cada entrada detrás de ésta es una licencia individual.
Los grupos de licencias definidos en la variable ACCEPT_LICENSE se prefijan con un símbolo
@
. Un ajuste que se demanda frecuentemente es el de permitir únicamente la instalación de software y documentación libres. Para conseguir esto, se pueden eliminar todas las licencias aceptadas (mediante -*
) y a continuación permitir solo las licencias en el grupo FREE, tal y como se muestra a continuación:ARCHIVO
/etc/portage/make.conf
Aceptar sólo software y documentación libreEn este caso, "free" está definido por la FSF y la OSI. Cualquier paquete cuya licencia no se ajuste a estos requisitos no se podrá instalar en su sistema.ACCEPT_LICENSE="-* @FREE"
Cuando Portage se queja...
Terminología.
Como mencionamos anteriormente, Portage es muy potente y soporta muchas características de las que carecen otras herramientas de gestión de software. Para comprender esto, explicaremos unos cuantos aspectos de Portage sin profundizar demasiado en los detalles.
Con Portage, diferentes versiones de un mismo paquete pueden coexistir en un sistema. Mientras otras distribuciones tienden a renombrar el paquete con sus versiones (por ejemplo freetype and freetype2). Portage usa una tecnología llamada SLOTs (ranuras). Un ebuild declara un cierto SLOT para su versión. Ebuilds con diferentes SLOTs pueden coexistir en el mismo sistema. Por ejemplo, el paquete freetype tiene ebuilds con SLOT="1" y SLOT="2".
También existen paquetes que proporcionan la misma funcionalidad pero están implementados de maneras distintas. Por ejemplo, metalogd, sysklogd, y syslog-ng son todos paquetes de registro del sistema. Aplicaciones que necesitan la disponibilidad de un "registrador del sistema" no pueden depender, por ejemplo, de metalogd, ya que el resto de registradores del sistema son igualmente válidos. Portage permite virtuals: cada paquete de registro del sistema se lista como una dependencia "exclusiva" del servicio de registro en el paquete virtual/logger de la categoría virtual, de esta forma las aplicaciones pueden depender del paquete virtual/logger. Cuando se instala el paquete, se obtendrá el primer paquete de registro mencionado, a menos que ya se haya instalado previamente un paquete que ofrezca el servicio (en este caso, la dependencia virtual ya está satisfecha).
Los programas del repositorio Gentoo puede residir en diferentes ramas. Por defecto, su sistema solamente acepta paquetes que Gentoo considera estables. La mayoría de los paquetes nuevos, cuando son aceptados, ingresan en la rama inestable. Esto implica que necesitan hacerse más pruebas antes de marcarlo como estable. Aunque los ebuilds de estos programas está en el repositorio Gentoo, Portage no los actualizará hasta que sean marcados como estables.
Algunos programas solo están disponibles para unas pocas arquitecturas. O los programas no funcionan en otras arquitecturas, o necesitan más pruebas, o el desarrollador que añade el programa al repositorio Gentoo no es capaz de verificar si el paquete funciona en diferentes arquitecturas.
Cada instalación de Gentoo adhiere un cierto perfil el cual contiene, entre otra información, la lista de paquetes necesarios para que el sistema funcione normalmente.
Paquetes bloqueados.
CÓDIGO Aviso de Portage sobre paquetes bloqueados (con --pretend)
Aunque las versiones recientes de Portage son lo suficientemente inteligentes para resolver los bloqueos de menor importancia sin necesidad de la intervención del usuario, ocasionalmente necesitará resolverlo a mano como se explica abajo.
Para solucionar un bloqueo, puede elegir no instalar el paquete o desinstalar primero el paquete conflictivo. En el ejemplo anterior, puedes optar por no instalar postfix o eliminar primero ssmtp.
También puede ocurrir que vea los paquetes en conflicto con operadores lógicos concretos, como por ejemplo
<media-video/mplayer-1.0_rc1-r2
. En este caso, actualizar a la versión más reciente del paquete bloqueante debería eliminar el bloqueo.También es posible que dos paquetes que aún no se han instalado se estén bloqueando mutuamente. En este caso (poco frecuente), se debería investigar por que necesitamos instalar ambos. En la mayoría de los casos se puede realizar con uno solo de los paquetes. Si no, por favor envíe un informe de error al sistema de seguimiento de errores de Gentoo.
Paquetes enmascarados (masked).
CÓDIGO Aviso de Portage sobre paquetes enmascarados
Cuando quiera instalar un paquete que no está disponible para su sistema, recibirá un error de enmascaramiento. Debería probar a instalar una aplicación distinta que este disponible para su sistema o esperar hasta que el paquete este disponible. Siempre hay una razón para que un paquete esté enmascarado:
Causa del enmascaramiento.
Descripción
~arch keyword
La aplicación no está suficientemente probada para estar en la rama estable. Espere unos días o semanas y pruebe de nuevo.
-arch keyword o -* keyword
La aplicación no funciona en su arquitectura. Si Vd. cree que si funciona infórmelo en nuestro sitio web Bugzilla.
sin keyword
La aplicacion aún no ha sido probada en su arquitectura. Solicite al equipo que se ocupa de esa arquitectura que la pruebe o pruébela Vd. mismo e informe del resultado en nuestro sitio web Bugzilla.
package.mask
El paquete se ha mostrado corrupto, inestable o aún peor y ha sido expresamente marcado como "no-usar".
profile
El paquete no es adecuado para su perfil (profile) actual. La aplicación, si es instalada, puede romper el sistema o simplemente no es compatible con el perfil en uso.
license.
La licencia del paquete no es compatible con los valores de ACCEPT_LICENSE. Permitir su licencia o el grupo de licencias adecuado indicándolo en /etc/portage/make.conf o en /etc/portage/package.license
Cambios necesarios en los ajustes USE.
CÓDIGO Aviso de Portage sobre necesidad de cambiar un ajuste USE
También puede que se muestre el siguiente mensaje de error, si no se ha habilitadoThe following USE changes are necessary to proceed: #required by app-text/happypackage-2.0, required by happypackage (argument) >=app-text/feelings-1.0.0 test
--autounmask
:CÓDIGO Error de Portage por ser necesario cambiar un ajuste USE
Esta advertencia y error suceden cuando se quiere instalar un paquete que no solo depende de otro paquete, sino que requiere que ese paquete se haya construido con un ajuste USE en particular (o un conjunto de ajustes USE). En el ejemplo dado, el paquete app-text/feelings necesita construirse con USE="test", sin embargo, este ajuste USE no está habilitado en el sistema.emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]". !!! One of the following packages is required to complete your request: - app-text/feelings-1.0.0 (Change USE: +test) (dependency required by "app-text/happypackage-2.0" [ebuild]) (dependency required by "happypackage" [argument])
Para resolver esta situación, puede añadir el ajuste USE requerido a sus ajustes globales en /etc/portage/make.conf, o definirlo específicamente para el paquete en /etc/portage/package.use.
Dependencias perdida.s
CÓDIGO Aviso de Portage sobre falta de dependencias.
Nombre ambiguo del Ebuild.
CÓDIGO Aviso de Portage sobre nombres de ebuilds ambiguos.
Dependencias circulares.
CÓDIGO Aviso de Portage sobre dependencias circulares
!!! Error: circular dependencies:
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2
Dos (o más) paquetes que quiere instalar dependen uno de otro y, por tanto, no pueden instalarse. Esto casi siempre se considera un error en el repositorio Gentoo. Por favor, vuelva a sincronizar después de un tiempo e inténtelo de nuevo. También puede comprobar Bugzilla para saber si se tiene conocimiento sobre el tema o si no, en cuyo caso informe sobre ello.
Fallo en la descarga.
CÓDIGO Aviso de Portage sobre error en la descarga
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)!!! Some fetch errors were encountered. Please see above for details.
Portage no es capaz de descargar las fuentes para una aplicación específica y tratará de continuar instalando el resto de aplicaciones (si es posible). Este fallo puede deberse a que un servidor réplica no esta bien sincronizado o a que el ebuild apunta a una localización incorrecta. El servidor donde residen las fuentes podría estar caído por alguna razón.
Pruebe después de una hora y vea si el problema persiste.
Protección del perfil del sistema.
CÓDIGO Aviso de Portage sobre paquete protegido por el perfil
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.
Está intentando eliminar un paquete que es parte fundamental de su sistema. Éste se haya en su perfil y es necesario, por tanto, no debería ser eliminado del sistema.
Errores en la verificación de la integridad (digest).
CÓDIGO Error de verificación de integridad
>>> checking ebuild checksums
!!! Digest verification failed:
Esta es una señal que hay algún problema con el repositorio Gentoo - muchas veces esto es porque un desarrollador ha cometido una equivocación al ingresar un paquete en el árbol.
Cuando falla la verificación de la integridad (digest), no intente recalcularla. El ejecutar ebuild algo manifest no va a resolver el problema; seguramente ¡lo empeorará!
En lugar de esto, espere una o dos hora que el árbol estabilice. Es probable que el error haya sido detectado enseguida, pero podrá tomar algún tiempo para que propague la corrección al repositorio Gentoo. Mientras espera, revise Bugzilla a ver si alguien ya ha reportado el problema o pregunte en #gentoo (IRC). Si no, siga adelante y cree un "bug" reportando el paquete roto.
Una vez que compruebe que el error ha sido reparado, tal vez quiera volver a sincronizar el repositorio Gentoo para obtener la suma de control reparada.
Hola estuve leyendo sobre la variable USE y modifique sus valores, desde la vez q instale gentoo, ahora quiero actualizar mi sistema con emerge -u --deep --newuse world pero mi problema surge porq aparece q es necesario instalar evolution y epiphany, pero yo no los ocupo y no quiero q se instalen, probe agregando los paquetes al archivo package.mask pero me marca error ya que gnome depende de esos paquetes, no hay alguna forma de excluir esos paquetes para q cuando actualize mi sistema no tenga q instalarlos y posteriormente desinstalarlos??
ResponderEliminarSi el paquete B se instala porque es dependencia de otro paquete A, significa que A necesita a B. De la misma forma que un coche necesita ruedas. Guste o no guste.
EliminarLa forma correcta de hacerlo no es como tú haces, porque básicamente estás rompiendo tu instalación cada vez que desinstalas una dependencia de otro paquete que esté instalado.
Primero tienes que ver qué paquetes en tu sistema dependen del paquete que tú no quieres instalar. Para ello puedes usar "equery d evolution", por ejemplo. Equery es parte de gentoolkit, así que emérgelo si no lo tienes.
En segundo lugar, muchas dependencias se pueden quitar de forma correcta, no mutilando tu sistema, usando las use flags. Por ejemplo, evolution seguramente pueda quitarse como dependencia de muchos paquetes usando USE="-eds". Así que añade dicha flag a tu make.conf. En cuanto a epiphany, creo que gnome depende en él, aunque no estoy seguro. En cualquier caso, el camino por el que ibas no es el correcto.
Usa equery para ver las dependencias de los paquetes que quieras eliminar, y luego postead los resultados y pregunta si tienes dudas.
EDIT: En cualquier caso, y por si no lo dije suficientemente claro, USE="-eds" no te asegura que evolution no se vaya a instalar. Ojo, si algún paquete lo necesita forzósamente, se instalará. De la misma forma que es imposible instalar gnome sin gtk o kde sin qt. Los use flags solo quitan el soporte cuando es opcional en un paquete (y si el ebuild ha sido diseñado para dicho propósito). De cualquier otro modo, dicho use no tendrá valor alguno.