Migrando a X modularPuede 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.
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.
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:
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.
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. El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logotipo y nombre de Gentoo. |
|