Gentoo Logo

Migrando a X modular

Contenido:

1.  Conceptos previos

Introducción

Puede preguntarse, ¿por qué el simple y sencillo paquete xorg-x11 se convirtió en casi 300 paquetes separados? Y ciertamente tiene razón en esto. =) No es algo que Gentoo esté haciendo independientemente de los desarrolladores principales de X.Org; ellos están dividiendo todos los paquetes en versiones separadas y nosotros estamos siguiendo esta decisión.

Puede leer los detalles en la página COMO: Migrar al servidor X modular.

2.  Comprobación de dependencias

Queremos enumerar las dependencias de la manera más precisa posible, de este modo la gente no tendrá información antigua por todos sus sistemas para características que nunca usa, tales como XPrint. Querrá depender directamente de la librería y los paquetes cabecera que necesite en lugar de cualquier tipo de virtual.

Tampoco podemos garantizar que la gente todavía tenga subpaquetes instalados simplemente porque tienen un metabuild instalado y, eliminando esa posibilidad de rupturas nos ahorrará un montón de tiempo que habríamos empleado en marcar fallos como INVALID.

Si encuentro algunos paquetes que dependen de los metabuilds tendré que, y no lo dudaré, molestar y hostigar al mantenedor por toda la eternidad.

El primer paso es, bien instalar X modular, bien encontrar a alguien que lo tenga instalado. Esto puede realizarse en una jaula chroot -- No hay necesidad siquiera de ejecutar X, simplemente necesita tener sus ficheros disponibles para la comprobación de dependencias.

Listado de Código 2.1: Obteniendo los scripts necesarios

$ wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs \
	http://dev.gentoo.org/~dberkholz/scripts/included_headers \
	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb

Importante: No use gentoolkit-0.2.1_pre9, produce una salida incorrecta. Mire https://bugs.gentoo.org/show_bug.cgi?id=111501.

El primer guión, linking_libs, comprueba el registro de compilación de su paquete para todas las librerías contra las que enlaza e imprime los paquetes a los que esas librerías pertenecen. Para obtener un registro de compilación, deberá habilitar PORT_LOGDIR en /etc/make.conf o usar redirección de la salida.

Listado de Código 2.2: Ejecutando linking_libs para el paquete gdm

$ ls /var/log/portage/*gdm* -l
-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
$ linking_libs /var/log/portage/8430-gdm-2.8.0.7.log

El segundo guión, included_headers, barre a través del código fuente del paquete en busca de líneas que comiencen por #include y obtiene los ficheros contenidos en <>. Hasta el 9 de septiembre de 2005, funciona para ficheros include del estilo "" de la misma forma que para <>.

El tercero de los guiones, checkdeps.rb, barre a través de los ficheros instalados por un paquete usando scanelf de pax-utils. Esto es útil para paquetes binarios o paquetes que por otra razón ocultan la salida de la compilación. Es un guión escrito en Ruby, por lo que depende de dev-lang/ruby y de app-misc/pax-utils. El cuarto guión, pkgutil.rb,es una dependencia de checkdeps.rb.

Ejecutando el primero de los guiones, debería obtener una lista de paquetes correcta para RDEPEND (para las librerías) y DEPEND (cabeceras y librerías). Si una librería aparece en la lista RDEPEND y no se muestra en la lista DEPEND, desconfíe; puede tratarse de una "falsa dependencia," (una librería a la que se enlaza sin razón aparente). Un ejemplo real de una dependencia como ésta es libXt; muchos paquetes comprueban las cabeceras de libXt para comprobar la existencia de X.

Ocasionalmente la búsqueda relativa en included_headers encontrará la cabecera incorrecta ya que hay muchas con el mismo nombre y por lo tanto devolverá un paquete incorrecto. Normalmente esto es bastante obvio y así las cabeceras Windows hacen pensar que app-emulation/wine es una dependencia.

Si especifica la opción -d, en algunas ocasiones obtendrá el mensaje "Not found!" de una librería o cabecera. Esto puede significar que ha desinstalado una cabecera que el paquete necesita desde el momento de su compilación, o se trata de una cabecera opcional que no está usando. En el caso de una librería, podría significar que ha desinstalado la librería o quizás era únicamente una librería estática construida internamente que nunca fue instalada.

Merece la pena emplear algún tiempo en averiguar si las librerías o cabeceras que no se encuentran necesitan ser añadidas a la lista de dependencias, particularmente en el caso de las cabeceras ya que no se necesita tener las cabeceras instaladas para realizar el escaneo.

En algunos casos, los paquetes requieren un servidor X de algún tipo. Sin embargo, si realmente no lo necesitan durante la instalación, le recomiendo que no lo añada a RDEPEND. Esto rompe instalaciones X sin cabeceras en las cuales los programas corren realmente en otra máquina, de modo que sólo necesita las librerías y cabeceras localmente.

Hay varios servidores X en el árbol, de modo que si necesita uno, por favor, inclúyalos todos. Los servidores de X modulares están en xorg-server; hay un servidor DirectFB en xdirectfb; kdrive ofrece pequeños servidores X; y desde luego <xorg-x11-7. Especifique la restricción de versiones en xorg-x11 para asegurarse un servidor X en lugar de un metabuild. En un futuro próximo, preveo que kdrive será integrado en xserver. Si necesita un servidor X, por favor, contacte con algún miembro del equipo X. Podemos crear un paquete virtual si existe un número suficiente de paquetes que lo necesiten.

3.  Estructura de las dependencias

Cuando añada las dependencias -- necesitará una estructura como esta:

Listado de Código 3.1: Estructuras RDEPEND/DEPEND

RDEPEND="|| ( ( x11-libs/libXfoo
			x11-libs/libXbar
			blah? ( x11-libs/libXblah )
			lo que se muestre en la ejecución de la librería
		)
		virtual/x11
	)

DEPEND="${RDEPEND}
	|| ( ( x11-proto/fooproto
			blah? ( x11-proto/blahproto )
			lo que se muestre en la ejecución de ambos scripts
		)
		virtual/x11
	)

Importante: Algunos de los resultados producidos por los scripts serán redundantes. Si el valor RDEPEND de una de las librerías incluye otra, no necesitará poner ambas en las dependencias. Si el valor DEPEND de una librería incluye un proto, lo necesitará en la lista DEPEND del paquete, De igual modo, candidatos para las librerías que hace que se incluyan otras librerías son libXaw, libXmu, libXpm, libXcursor, libXt. Simplemente haga emerge -ep $library | grep lib[SIX]. También recuerde que otros paquetes como gtk+ han sido migrados a dependencias modulares, de forma que hace que se incluyan las librerías necesarias igualmente.

Nota: Dos indicadores USE diferentes aparecen en X, pero uno no depende del otro. En este caso, necesitará, bien duplicar la dependencia de la sección X, bien definirla en otro lugar e incluirla como ${X_DEPEND}. Si está definida en otro lugar, recuerde también incluir las partes específicas para cada indicador USE.

El objetivo en este caso es hacerlo por defecto la nuevo X modular, pero permitir a la gente que también resuelva sus dependencias con el paquete xorg-x11 antiguo y monolítico. Estamos eliminando virtual/x11 completamente para obligar la enumeración de las dependencias adecuadas.

Para la ejecución inicial a través del árbol, el esfuerzo en la migración únicamente corrige los ebuilds más recientes disponibles para los usuarios ~arch users y cualquier cosa más reciente (KEYWORDS=-* o package.mask). Los mantenedores de los paquetes individuales pueden elegir hacer esto y permitir que las ebuilds no migradas gradualmente desaparezcan del árbol. Sin embargo querrán migrar todas sus ebuilds de una vez. Repoman pronto terminará su ejecución cuando cualquier ebuild tenga una dependencia fuerte con virtual/x11.

Importante: Esto debería permitir a los usuarios ~arch usar el X modular por defecto mientras envían usuarios no-~arch a virtual/x11.

4.  Tratando los indicadores USE

Muchas personas tienen el indicador USE xinerama desactivado. Sin embargo, si cuando está ejecutando included_headers, x11-proto/xineramaproto se muestra como dependencia, entonces añádalo a DEPEND detrás del USE xinerama y añada x11-libs/libXinerama a RDEPEND detrás del USE xinerama.

Caleb advirtió una buena cuestión, ésta es: ¿Cómo tratamos con todos los indicadores USE en paquetes que tienen una gran cantidad de dependencias de librería opcionales?. En muchos casos, tendrá sentido forzar los indicadores a on u off en todas las ocasiones. También se puede hacer de forma más sencilla agrupando indicadores. Asegúrese de que nombra los indicadores por su función y no por las librerías o paquetes que usan.

5.  Poniendo sus correcciones en el árbol

Si es un desarrollador, haga commit de los mismos. Si no, abra un nuevo informe de fallo, asígnelo a los mantenedores del paquete (en metadata.xml). Haga que bloquee el fallo #112675. Adjunte un parche para corregir las dependencias.



Imprimir

Página actualizada 3 de enero, 2006

Sumario: Esta guía muestra cómo migrar paquetes usados en el nuevo X.Org modular.

Donnie Berkholz
Autor

José María Alonso
Traductor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.