SYNC (el servidor rsync) sale fuera del make.conf

gentoo-powerA partir de la versión de Portage 2.2.16, la configuración del servidor rsync que contiene la URI para la actualización del árbol de Portage, sale fuera del archivo /etc/make.conf donde estaba antes en una línea con este formato:

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

a partir de ahora se utilizará un sistema más limpio, flexible y potente para organizar, configurar y seleccionar los repositorios de Gentoo. Tanto los del árbol principal de Portage, como para los overlays de Layman y overlays locales.

Nuevo sistema:

creamos el nuevo directorio repos.conf:

sudo mkdir /etc/portage/repos.conf

y para mantener la configuración estandar de Gentoo tan sólo es necesario hacer:

sudo cp /usr/share/portage/config/repos.conf /etc/portage/repos.conf/gentoo.conf

con lo que en /etc/portage/repos.conf/ tendremos un nuevo archivo de configuración repos.conf con este aspecto:

*******************************************************

[DEFAULT]
main-repo = gentoo

[gentoo]
location = /usr/portage
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
auto-sync = yes

*******************************************************

Tal y como vemos, tenemos la localización del árbol de Portage en el sistema, el tipo de sincro, puede ser: rsync, git (repo git), svn (repo subversion), webrsync (emerge-webrsync), cvs y laymansync (layman overlays). Lógicamente también aparece la URI del servidor y se puede determinar si por defecto se sincronizará ese repo o no.

La URI principal tal y como vemos es:

# Default: "rsync://rsync.gentoo.org/gentoo-portage"

pero tenemos más opciones:

# rotación: "rsync.us.gentoo.org/gentoo-portage"
# una URI de rotación de Gentoo que permite distribuir la carga de servidores rsync para optimizarlos.

o servidores por zonas geográficas, puedes elegir el que tengas más cerca:

# Europe: "rsync://rsync.europe.gentoo.org/gentoo-portage"
# South America: "rsync://rsync.samerica.gentoo.org/gentoo-portage"
# North America: "rsync://rsync.namerica.gentoo.org/gentoo-portage"
# Asia: "rsync://rsync.asia.gentoo.org/gentoo-portage"
# Australia: "rsync://rsync.au.gentoo.org/gentoo-portage"

Pues ya podemos eliminar la línea SYNC de nuestro archivo /etc/make.conf (si no lo hacemos Portage (>2.2.16) se quejará a la primera oportunidad que tenga a través de emerge, ya sabéis que Portage es muy parlanchín 😉 ).

Tal y como hemos dicho, la nueva configuración también afecta a los overlays de Layman y a los overlays locales, mediante un archivo /etc/portage/repos.conf/layman.conf y /etc/portage/repos.conf/overlay-local.conf pero como esto supone una actualización de Layman y Overlays Locales, lo trataremos en otra entrada próximamente.

más información (en inglés):

https://wiki.gentoo.org/wiki/Project:Portage/Sync

wallpaper-gentoo-morpheus

Anuncio publicitario

profundizando en Gentoo -> Portage -> emerge -> equery

VACA POLLOTal y como sabemos, Portage es el cerebro y el sistema nervioso de Gentoo. Ya publicamos una entrada con los comandos básicos de emerge para Portage, pero para sacarle todo el partido, tenemos que profundizar un poco en Portage.
Como todo en la vida, Portage se aprende usándolo, pero me voy a permitir aportar una lista de «tips» que he ido aprendiendo en mi gestión cotidiana de Gentoo.

tip 1.

Puede ocurrir, que al actualizar un día Gentoo, nos encontremos algún bloqueo de paquetes, siempre se resuelven trasteando un poco, normalmente enmascarando o desinstanlando alguno para permitir la actualización, pero si en ese momento no tenemos tiempo de ponernos a eso y queremos actualizar, siempre existe esta posibilidad:

Actualizar portage excluyendo un paquete o varios (ejemplo vlc):

sudo emerge -uaD world --exclude vlc

En este caso actualizaríamos todo el sistema excluyendo el paquete «vlc» (muy útil si algún paquete nos da problemas y queremos actualizar antes de resolverlos).

*********************************************************

tip 2.

En Gentoo, cuando hacemos el famoso sudo emerge -ua world , lo que hacemos es comprobar si hay nuevas versiones en Portage de los paquetes que han sido explícitamente instalados por nosotros (no de manera indirecta como dependencias), por lo tanto, hay un archivo llamado world en algún sitio donde están listados todos esos paquetes.

¿dónde está el archivo world?

Pues lo encontramos aquí: /var/lib/portage/world

Lógicamente, como es un archivo de texto plano, podemos editarlo y eliminar a mano los paquetes que deseemos, pero existe una forma más elegante de hacerlo:

Eliminar paquetes del archivo world: (ejemplo conky)

sudo emerge conky --deselect

Con lo cual ya no tendremos «conky» en nuestro archivo world y no se actualizará en los updates. Siempre podremos actualizarlo manualmente «emergiendolo» de manera individual.

*********************************************************

tip 3.

Relacionado con el anterior, si quiero instalar un paquete pero que no se incluya en el archivo world, tan sólo tengo que añadir la opción --oneshot (-1)

ejemplo:

sudo emerge -1 conky

(a partir de ahora «conky» no se actualizará en los emerges world).

*********************************************************

tip 4.

Esto es extraño, pero me parece interesante. Emerge puede instalar todas las dependencias de un paquete, sin instalar el paquete mismo. Para ello se usa la opción --onlydeps (-o)

sudo emerge -o vlc

(lo que instalaría las dependencias que necesita «vlc» sin instalar el paquete «vlc»).

*********************************************************

Veamos ahora algunos tips basados en equery, que es una herramienta muy potente para obtener información sobre paquetes de Portage. Para poder usar equery hay que instalar gentoolkit:

sudo emerge gentoolkit

tip 5.

Listar todos los paquetes que dependen de un paquete con «depends» (d):
Es importante darse cuenta de que esto no son las dependencias, sino todo lo contrario:

ejemplo «libav»

equery depends libav

o

equery d libav

Lo que nos dará todos los paquetes que necesitan a libav para funcionar (no las dependencias de libav)

*********************************************************

tip 6.

Podemos saber justo lo contrario a depends, esto es, todos los paquetes de los que depende un paquete concreto con «depgraph» (g) sus dependencias (ahora sí)

O sea, a depgraph se le pasa un paquete y encontrará los paquetes de los que éste depende (no los que dependen de él). Cuando encuentre una dependencia, se buscará recursivamente todas las dependencias de ese nuevo paquete.

ejemplo «leafpad»

equery depgraph leafpad

o

equery g leafpad

Lo que nos listará todas los paquetes que necesita «leafpad», o sea sus dependencias.

NOTA.- Para evitar confusiones entre «equery d» y «equery g», hay que recordar que una dependencia en LINUX no es un paquete que depende del que estudiamos, sino un paquete que NECESITA el paquete en cuestión. Por lo que las dependencias del paquete «vlc» se buscan con «equery g vlc».

*********************************************************

tip 7.

Podemos listar todos los archivos instalados por un paquete con «files» (f)

equery files --tree vlc

(informa como árbol y con sus rutas de todos los archivos instalados por vlc)

*********************************************************

tip 8.

Mostrar los metadatos de un paquete con «meta» (m)

equery meta vlc

(muestra todos los metadados, toda la información relevante de un paquete. Muy útil).

*********************************************************

tip 9.

Si queremos encontrar el paquete al que pertenece un fichero concreto instalado en el sistema, podemos saberlo con «belongs» (b)

equery belongs -e /usr/bin/glxgears

nos responde que /usr/bin/glxgears ha sido instalado por el paquete mesa-progs:

* Searching for /usr/bin/glxgears … x11-apps/mesa-progs-7.5.1 (/usr/bin/glxgears)

*********************************************************

y para finalizar dos tips relacionados con las etiquetas USE (USE flags):

tip 10.

Podemos buscar paquetes que tienen un determinado ajuste USE con «hasuse» (h)

equery hasuse qt3 qt4

(lista todos los paquetes compilados con las etiquetas USE especificadas, en este caso nos informará de todos los paquetes compilados con las USE flags «qt3» y «qt4»)

*********************************************************

y, tip 11.

Listar los ajustes USE de un paquete con «uses» (u)

equery uses vlc

(muestra y explica todos los posibles USE para un paquete, y nos muestra en rojo los activos, en azul los que no).

Estas son sólo algunas de la posibilidades de emerge y equery, tal vez las más interesantes, pero hay muchas más. Te animo a descubrirlas por ti mismo investigando sus páginas man:

man emerge

man equery

Si te apetece compartir algún truco que utilices con emerge o equery utiliza los comentarios.

Si has llegado hasta aquí, es que eres todo un gentoocito.
A veces me pregunto cuántos seremos entre ese 2% escaso de usuarios GNU-LINUX, los usuarios de Gentoo, ¿tal vez un 1% de ese 2%?
Tú, yo, y alguno más.Pocos, pero los mejores siempre son pocos.

😉

emerge

crear un overlay local en Gentoo

screenfetchEn una entrada anterior veíamos como gestionar overlays mediante Layman:

Overlays y Layman en Gentoo

veamos ahora como tener nuestro propio overlay local, en el que podremos meter los ebuilds que nosotros deseemos. La ventaja de esto es que no hay porqué aceptar todo lo que traiga un overlay externo, sino que podemos buscar por nuestra cuenta ebuilds que nos interesen para emergerlos con Portage.

El overlay local podemos tenerlo donde queramos, pero un buen sitio por defecto es:
/usr/local/portage/

Lo primero que hay que hacer es crear dos directorios necesarios dentro, que son: metadata y profiles:

sudo mkdir -p /usr/local/portage/{metadata,profiles}

ahora hay que crear dentro de la carpeta profiles un archivo con el nombre de nuestro propio overlay, y que contenga el nombre del overlay (en este caso «mi-overlay»):

sudo echo ‘mi-overlay’ > /usr/local/portage/profiles/mi-overlay

y creamos el archivo layout.conf dentro de metadata que contenga «masters = gentoo»:

sudo echo ‘masters = gentoo’ > /usr/local/portage/metadata/layout.conf

definimos a Portage como propietario para que pueda controlar el overlay:

sudo chown -R portage:portage /usr/local/portage

Pues ya sólo nos queda informar a Portage de dónde está nuestro nuevo overlay local para que pueda usarlo. Para ello agregamos en el famoso /etc/portage/make.conf la siguiente línea:

PORTDIR_OVERLAY=»/usr/local/portage ${PORTDIR_OVERLAY}»

Lógicamente si es esa la ruta en la que lo hemos instalado.

Con esto ya está instalado nuestro nuevo overlay local. Veamos ahora cómo añadirle un ebuild que nos interesa instalar y que no está en el árbol oficial de Portage o, tal vez simplemente, que hemos encontrado una versión más moderna.

Podemos buscar y descargar ebuilds por ejemplo aquí:

http://gpo.zugaina.org/

descargamos el ebuild que nos interesa (en nuestro ejemplo vamos a suponer que hemos encontrado una versión más moderna de programa screenfetch de la que tenemos en el árbol oficial de Portage. Nos la descargamos.

http://gpo.zugaina.org/app-misc/screenfetch

En nuestro overlay local hay que mantener el mismo sistema que en el árbol de Portage, por lo que cada ebuild debe estar en su directorio y este a su vez dentro del directorio de su grupo de programas, en este caso:

app-misc/screenfetch/

Creamos los directorios necesarios:

sudo mkdir -p /usr/local/portage/app-misc/screenfetch

Luego copiamos el ebuild que nos hemos descargado dentro de /usr/local/portage/app-misc/screenfetch

Entramos en el directorio:

pushd /usr/local/portage/app-misc/screenfetch/

Creamos el archivo manifest dentro mediante la orden:

sudo repoman manifest

salimos del directorio mediante el comando:

popd

y nos aseguramos de que Portage sea el propietario recursivo de todo el árbol de archivos de nuestro overlay local:

sudo chown -R portage:portage /usr/local/portage

Y ya está. Ahora podemos emerger el nuevo ebuild. Si era un paquete que no estaba en Portage veremos que ahora sí que está, y si, como es nuestro caso, hemos encontrado una versión más moderna, veremos que Portage nos la propone para instalar:

sudo emerge -a screenfetch

En muchos casos Portage nos informará al intentar instalar un ebuild desde nuestro overlay local que se necesita añadir la autorización en el /etc/portage/package.accept_keywords

# screenfetch (overlay local)
app-misc/screenfetch ~amd64

Pues ya está hecho, a Portage siempre se le obedece.