HOWTO Usar Portage Correctamente
De Gentoo Linux Wiki
| Kernel & Hardware • Red y Servicios • Portage • Relacionado con el Sistema • Servidor X • Juegos • Misceláneos |
Última revisión: 14-5-5
[editar] Notas a la traducción
Este articulo es una traducción del how-to How to use portage correctly, iniciado y mantenido por GaMMa. Como he visto que alguna gente sigue usando el flag -U al actualizar su sistema, traduzco al final el mensaje de Eartwhings en el hilo emerge -update includes unwanted packages. En las últimas revisiones he incluido algo de material propio.
[editar] Introducción
Portage es un recurso excelente cuando se usa adecuadamente. El uso incorrecto puede llevar a un sistema sobrecargado con paquetes no traceables (no se puede decidir si están ahí a petición del usuario, son dependencias de algo que necesita el usuario o si simplemente sobran), así como a un fichero world corrupto. Esta guía pretende ayudar al usuario a mantener mejor el sistema.
[editar] Uso de Portage
[editar] Emerger paquetes
Al emerger un paquete marcado como inestable es recomendable hacerlo mediante
# emerge algo
NO USÉIS ACCEPT_KEYWORDS=~x86, ya que se seguirá ~x86 para todas las dependencias, y esto podría no ser lo que deseáis. Lo aconsejable es intentar instalar primero el paquete. Si no es la versión deseada, intentar forzarlo a esta versión como se indica más adelante. A continuación reintentar la instalación. Si en alguna dependencia se encuentra con que necesita un paquete inestable, volver a realizar el mismo proceso para esa dependencia y volver a instalar el paquete original de nuevo. Repítelo con las dependencias que pudieras necesitar, hasta que el paquete esté instalado. Sí, puede parecer engorroso. Pero al menos sabes exactamente qué paquetes inestables se instalan en tu sistema.
AVISO: Emerger un ebuild directamente (emerge algo.ebuild) ha causado problemas a algunos usuarios y no debe hacerse. En algunas situaciones el paquete no se añade al fichero world. Este método no informará al usuario cuando aparezcan nuevas versiones (inestables) de este paquete, incluso si contienen correcciones esenciales.
[editar] Paquetes inmensos con dependencias que no deseamos
Esto pasa con "monstruos" como KDE o Gnome. Lo instalan todo, todos los programas asociados, independientemente de que nos interesen o no. Por ejemplo, a mí no me hace ninguna falta el paquete kdeedu. En tiempos, la solución era "inyectar" los paquetes, con la versión específica. Ahora, lo que se hace es añadir una línea al fichero /etc/portage/profile/package.provided, que ofrece una funcionalidad similar. Así pues, para evitar que se instale un paquete no deseado, haremos
# echo 'categoria/paquete-versión' >> /etc/portage/profile/package.provided
Hay quien habla de las bondades de editar el ebuild y eliminar las dependencias que no se deseen. Esto no tiene por qué sobrevivir a un emerge sync. Para el caso de kdeedu:
# echo 'kde-base/kdeedu-3.3.0' >> /etc/portage/profile/package.provided
OJO
Algunas dependencias son innecesarias (kde->kdeedu), y no hay problema en "inyectarlas" o en añadirlas al fichero package.provided. Sin embargo, algunas otras dependencias son necesarias. Cuando esto suceda, portage pasará del fichero package.provided.
También pasará de ese fichero cuando haya actualizaciones para los paquetes de world. Así pues, si xorg está en nuestro fichero world (cosa probable si habéis migrado desde xfree) y hay una actualización disponible, os la instalará, por mucho que queráis "inyectarla". Para evitar estas actualizaciones no deseadas, tendréis que enmascarar el paquete.
[editar] Mantener paquetes
A veces, al hacer 'emerge -u world', Portage quiere rebajar la versión de un paquete. Esto suele suceder en los paquetes inestables que tengamos instalados. Para evitarlo hay que crear el directorio /etc/portage.
# mkdir -p /etc/portage
La opción -p de mkdir evitará que aparezca un mensaje de error en caso de que el directorio ya exista (gracias Earthwings por la explicación).
En el fichero /etc/portage/package.keywords, se añade una línea con el nombre completo del paquete seguido por ~x86. Por ejemplo, para que Portage reconozca que queremos usar versiones inestables de Gaim, basta con hacer en una consola
# echo net-im/gaim ~x86 >> /etc/portage/package.keywords
Esto ha de hacerse para todos los paquetes inestables que no queramos ver rebajados.
También podemos habilitar versiones específicas de algún paquete, para que cuando aparezca una nueva versión inestable, el sistema no actualice ese paquete. Para ello, ha de hacerse un
# echo =app-loquesea/algo-version ~x86 >> /etc/portage/package.keywords
donde version es la versión del paquete, sin el -rN. La línea anterior sólo permitirá que se instale una versión determinada del paquete. Sin embargo, las revisiones seguirán estando enmascaradas por ~arq. Para permitir que el paquete se actualice siguiendo las siguientes revisiones, usaremos lo siguiente:
# echo ~app-loquesea/algo-version ~x86 >> /etc/portage/package.keywords
Aún así, hay veces en las que Portage quiere rebajar la versión de un paquete. Habitualmente hay una razón de peso para ello. Aunque también hay excepciones (N del T: NUNCA rebajéis la versión de la glibc). Por ejemplo, podríais necesitar los linux-headers-2.6 (aunque xorg no compila con ellos). Para evitar que portage nos devuelva linux-headers-2.4, haremos
# echo sys-kernel/linux-headers -* >> /etc/portage/package.keywords
Algunos paquetes intentan volver una y otra vez a nuestro sistema. Los usuarios de xorg nos encontramos a menudo con que Portage quiere instalarnos xfree. Para solucionarlo, añadiremos a /etc/portage/package.mask el nombre completo del paquete que queremos enmascarar. Así:
# echo x11-base/xfree >> /etc/portage/package.mask
También hay veces en las que los paquetes están fuertemente enmascarados, no sólo por ~arq. Si estamos interesados en uno de estos paquetes, añadiremos el nombre completo a /etc/portage/package.unmask. Un paquete en estas circunstancias es realone:
# echo media-video/realone >> /etc/portage/package.unmask
También hay un package.use por si quieres modificar tus variables USE sólo para un paquete. Por ejemplo, para evitar que se compile la interfaz gráfica de mldonkey, yo hice
# echo net-p2p/mldonkey -gtk >> /etc/portage/package.use
[editar] Las dependencias "virtuales" y los perfiles: el caso de xorg-x11
El caso de XOrg es bastante más problemático. No podemos simplemente enmascarar XFree, puesto que algunos paquetes "misteriosamente", intentarán reinstalarlo. La explicación es sencilla: esos paquetes suelen depender de un servidor X, por una dependencia llamada "virtual/x11". Por defecto, dicha dependencia se satisface únicamente instalando x11-base/xfree. Sin embargo, las dependencias virtuales permiten una gestión más flexible: permiten tener alias y alternativas. La forma de proceder es crearse un directorio /etc/portage/profile
# mkdir -p /etc/portage/profile
e introducir en el fichero virtuals las dependencias de los paquetes "virtuales" que queremos personalizar:
# echo 'virtual/xfree x11-base/xorg-x11 virtual/x11 x11-base/xorg-x11 virtual/opengl x11-base/xorg-x11 virtual/glu x11-base/xorg-x11' >> /etc/portage/profile/virtuals
[editar] Manteniendo el fichero world
A veces algunos paquetes no se añaden al fichero world por cualquier razón (uso del flag -U, se emergió el ebuild en vez del paquete). Para intentar arreglarlo, tenemos la herramienta regenworld, que buscará los paquetes que tengamos instalados y regenerará el fichero world de una manera más adecuada. Usarla es tan difícil como ejecutar como root
# regenworld
Si nuestro fichero world está realmente mal, este hilo y este otro contienen scripts e información de cómo regenerarlo por completo. El script de este último me vino a mí (a ArsDangor) de perlas una vez que me encontré con un fichero world realmente jodido por culpa del flag -U (y de alguna cosilla más). Es una herramienta mucho más minuciosa y potente, pero también más lenta.
[editar] La opción -U es MALA
Tan mala que ha sido declarada obsoleta y tiene sus días contados. Este es el post de Earthwings al respecto, traducido como mejor puedo...
Razón 1: Problemas con los SLOTs. Esto le ha sucedido a bastante gente que quería gimp-2 en vez de gimp-1.2. Imaginad que gimp-1.2 está marcado como estable, y en el SLOT 1. Imaginemos ahora que gimp-2 está marcado como inestable y en el SLOT 2. Así pues, alguien que pase de este mensaje hará
# ACCEPT_KEYWORDS='~x86' emerge gimp
y se instalará gimp-2. Después, querremos actualizar el sistema y haremos algo como
# emerge -U world
Esto instalará gimp-1.2, porque gimp está en el fichero world. Y el flag -U no gestiona los SLOTs como uno desearía.
Razón 2: Problemas si se eliminan ebuilds de Portage Imaginemos que hay dos versiones del paquete m en Portage: m-1.4 marcada estable y m-1.6 marcada inestable. Quieres la versión inestable y la instalas como el gimp, antes. Pasado un tiempo, actualizas el sistema con emerge -U world. Pero en ese tiempo ha salido m-1.6.1 corrigiendo bugs realmente importantes. Ahora hay dos posibilidades: a) m-1.6 fue eliminado de Portage. En tal caso, intentará instalarte m-1.4 Así pues, la opción "-upgrade-only" no se cumple. b) si m-1.6 no fue eliminado de Portage, la situación podría ser aún peor. Seguirás con tu m-1.6 hasta que algo mayor que m-1.6 sea marcado como estable. Si los bugs que se arreglaron en la versión 1.6.1 eran problemas graves de estabilidad o seguridad, seguirás sufriendo cuelgues y cualquier ataque externo tendrá éxito.
¿Cómo solucionar este problema? Volviendo a leer este post. =D
[editar] ¡¡Horror!! ¡Tengo el mismo paquete instalado muchas veces!
Ante todo, mucha calma. Esto puede ser o no ser malo. Por ejemplo, algunos paquetes no compilan bajo GCC 3.4. Pero el GCC 3.4 genera ejecutables y bibliotecas notablemente más rápidos que el 3.3. Por lo tanto puede ser conveniente tener varias versiones instaladas. Gentoo necesita dos versiones de algunos paquetes, como db. Para esto están los SLOTs.
Al ver que hay varios paquetes "repetidos" en el sistema, mucha gente tiene la tentación de hacer
# emerge prune
Esta solución es ineficaz y problemática. La opción prune no respeta los SLOTs. Lo que hará será desinstalar todas las versiones del paquete en cuestión, salvo la versión instalada más recientemente. Así pues,
# emerge prune gtk
hará que sólo funcionen las aplicaciones compiladas con GTK 2 (si esta fue la última versión que se instaló), y que dejen de funcionar las aplicaciones compiladas con GTK 1. ¡Adiós al XMMS!
¿Cuándo conviene desinstalar paquetes duplicados? Cuando hay varias versiones en el mismo SLOT. ¿Cómo lo sabremos? Con la herrmienta qpkg.
# qpkg -d -s
nos indicará qué paquetes tienen varias versiones metidas en el mismo SLOT. Entonces, podremos desinstalar las versiones duplicadas. Si estamos seguros de cómo fueron instaladas, podríamos usar la opción prune. Si no, habrá que desinstalarlas "a mano", con la opción -C.
[editar] Paquetes en los que se modifican las variables USE
En ocasiones modificamos las variables USE que afectan a los paquetes que tenemos instalados. Bien sea a través de nuestro make.conf o por el fichero package.use, puede que deseemos añadir o eliminar una característica al sistema que tenemos. Para actualizar todos los paquetes que se vean afectados por ese cambio en sus USE, tenemos la opción --newuse, que nos actualizará los paquetes cuyas USE hayan cambiado.
[editar] Para frikis e impacientes: overlays
Algunas veces somos tan cagaprisas que no podemos esperar a que un paquete entre en portage. Hay algo que nos impulsa a tenerlo ya. En este caso, alguno estará tentado de bajarse el tar.gz de la web, y, a mano, hacer
# ./configure && make && make install
Entonces tendremos multitud de ficheros que portage no sabrá reconocer, basura por doquier.
La forma más adecuada de manejar esta situación es conseguir un ebuild para el paquete. Muchos proyectos cuelgan en la página web un ebuild, junto a los RPMs y los DEBs. En otros casos, basta con usar el ebuild de una versión anterior que hubiera en Portage. Para que Portage lo trate adecuadamente, crearemos un directorio para los ebuilds personales (overlays). Así:
# mkdir -p /usr/local/portage
Después, declararemos en nuestro make.conf la variable PORTDIR_OVERLAY:
PORTDIR_OVERLAY=/usr/local/portage # O el directorio que hayáis definido vosotros
Y ahora, sólo nos queda crear la categoría adecuada para la versión del paquete que queramos instalar. Y meter en su directorio el ebuild. En mi caso, quería aMule cvs (que no está en Portage) y wxGTK 2.5.5 (la versión más reciente en Portage es la 2.5.3). Así pues, me bajé el ebuild de amule-cvs de la página de amule. Y luego creé el directorio y metí el ebuild dentro:
# mkdir -p /usr/local/portage/net-p2p/amule-cvs # cp ~/amule-cvs-2.ebuild /usr/local/portage/net-p2p/amule-cvs
Lo mismo para wxGTK. Aprovecharemos el ebuild que ya hay en Portage.
# mkdir -p /usr/local/portage/x11-libs/wxGTK # cp /usr/portage/x11-libs/wxGTK/wxGTK-2.5.3.ebuild /usr/local/portage/x11-libs/wxGTK/wxGTK-2.5.5.ebuild
Ahora, Portage nos ofrecerá la opción de pasar de wxGTK 2.5.3 a wxGTK 2.5.5.
# emerge -puv wxGTK These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] x11-libs/wxGTK-2.5.5 -debug +gtk2 +no_wxgtk1 -odbc +opengl +unicode 7,100 kB [1] Total size of downloads: 7,100 kB Portage overlays: [1] /usr/local/portage
Y si buscamos amule-cvs, Portage lo encontrará:
# emerge -s amule-cvs
[ Results for search key : amule-cvs ]
[ Applications found : 1 ]
* net-p2p/amule-cvs
Latest version available: 2
[...]
Antes de instalar, recordad que hay que hacer el resumen (digest) del ebuild.
# ebuild /usr/local/portage/net-p2p/amule-cvs/amule-cvs-2.ebuild digest # ebuild /usr/local/portage/x11-libs/wxGTK/wxGTK-2.5.5.ebuild digest
Y ya podemos instalar los nuevos paquetes, sin volver loco a Portage.
[editar] package.mask y package.unmask
Los paquetes fuertemente enmascarados (hard-masked) aparecen en el:
/etc/portage/package.mask
Aunque el portage ya define los suyos en:
/usr/portage/profiles/package.mask
Para quitarles la restricción de enmascarado hay que editar el:
/etc/portage/package.unmask
Imaginate que gcc esta hard-masked. Entonces deberias editar /etc/portage/package.unmask y alli insertar:
sys-devel/gcc
Para hacer un unmask de todas las versiones, es decir, el paquete estara disponible, independientemente de todas las versiones.
Ahora supongamos que esta enmascarado gcc-4.1.1 y quieres desenmascararlo para poder instalarlo, entonces inserta una linea en /etc/portage/package.unmask lo siguiente:
=sys-devel/gcc-4.1.1
De este modo quedara desenmascarado. Puedes usar tambien simbolos de desigualdades, es decir:
>=sys-devel/gcc-4.1.1
Esto desenmascarara todos los gcc que sean mayores o iguales en version al 4.1.1.
Recuerda que si quieres desenmascarar un paquete "entero" no debes poner ningun simbolo, unicamente CATEGORIA/NOMBREPAQUETE, mientras que si quieres alguna versión en especial sería
[<,>][=]CATEGORIA/NOMBREPAQUETE-VERSION.
/etc/portage/package.mask es para todo lo contrario, para enmascarar paquetes que no lo están, que a veces también es *MUY* util. Así que si estabas introduciendo aquí el nombre de paquete y ya estaba enmascarado en portage, lo estabas enmascarando dos veces ;)
Si al hacer algun emerge te sale un mensaje del tipo "Invalid atom in..." ten por seguro que has cometido algun error en /etc/portage/package.mask o /etc/portage/package.unmask.
[editar] Conclusiones
Esta guía te evitará la mayor parte de los problemas que te pudieran aparecer al actualizar el sistema.
emerge -uDav --newuse world
es la mejor manera de actualizar todo el sistema. El flag u es para actualizar (update), D para actualizar las dependencias (deep), a para preguntar si continuar (ask) y v es "verboso", para así poder ver las variables USE que pudieran afectar a la compilación y dependencias de cada paquete.
Hay más información sobre otras opciones de Portage en la guía básica y en la guía avanzada de Portage, en la documentación oficial de Gentoo.
[editar] Agradecimientos
Muchas gracias a Earthwings por la calidad de sus explicaciones, y por la rapidez en responder a mis dudas. Gracias, evidentemente, a GaMMa por haber escrito un post tan útil y haberlo mantenido soberbiamente actualizado. Y a todos los que hayáis contribuido o vayáis a contribuir a este hilo.
[editar] Créditos
- Post Original por GaMMa
- Traducción por Arsdangor
- Portado al wiki por Navegante
- Material sobre virtuales, overlays y paquetes duplicados por ArsDangor.
