El COMO de los Ebuilds separados de KDE

1.  Los ebuilds separados de KDE

¿Qué son?

Hasta enero del 2005, los únicos ebuilds de KDE en Portage eran los 'monolíticos'. Eso significa que solamente existían 15 ebuilds (kdebase, kdenetwork, ...), y cada uno de ellos instalaba muchas aplicaciones que, de hecho, no dependían uno del otro. Esto era claramente una situación no muy óptima que digamos, y no sigue la filosofía Gentoo; pero fue tolerado por un largo tiempo.

Los nuevos ebuilds 'separados' (para konqueror, kmail, ...) han rectificado esta situación proporcionando ebuilds separados para todas las aplicaciones de KDE. Esto nos da un gran total de unos 330 nuevos ebuilds en la categoría kde-base.

Todavía proporcionamos ebuilds 'monolíticos' para KDE 3.5 (hasta la versión 3.5.9) que interoperan limpiamente con los 'separados'. Sin embargo, los ebuilds separados son la nueva forma por defecto y no habrá más ebuilds monolíticos después de KDE 3.5.9.

También se encuentran los ebuilds separados para el Koffice. Estos nos proveen de kword, kugar, etc. como paquetes separados.

¿Cómo usarlos?

En el momento de edición de este documento, la última versión de KDE es la 3.5.9. La última versión inestable (~arch) es la 3.5.10. En Portage se encuentran los correspondientes ebuilds separados y monolíticos para ambas versiones. La última versión 4.1.x también está en el árbol.

• Para realizar un emerge de un paquete particular, como kmail, simplemente debe ejecutar emerge kmail.
• Para realizar un emerge del entorno básico del KDE en donde puedas realizar un login del una sesión minimalística del KDE, tienes que ejecutar emerge kdebase-startkde
• Finalmente, para obtener el equivalente exacto a lo realizado por un ebuild monolítico (por ejemplo, para instalar todas las aplicaciones incluidas en kdebase) con ebuilds separados, debe ejecutar emerge kdebase-meta (o kdepim-meta, etc.). Para instalar absolutamente todo el paquete KDE ejecute emerge kde-meta

¿Cómo actualizar ebuilds de monolíticos a separados?

Si tiene instalados los ebuilds monolíticos de KDE 3.4.x ó 3.5.x, debe desinstalarlos antes de proceder con los ebuilds separados. No obstante, este proceso puede ser hecho por partes, es decir, puede desinstalar los ebuilds monolíticos uno a uno sin tener que desinstalar todo KDE de una vez.

Si tiene dudas, recuerde que hay dependencias bloqueantes entre cada ebuild monolítico y los ebuilds separados que derivan del primero. Portage no permitirá que se cree un estado ilegal, así que cualquier emerge o unmerge que permita estará correcto.

Ventajas de utilizar los ebuilds separados

Aquí se encuentra una breve lista de los beneficios obtenidos al pasarnos a los ebuilds separados:

• La mayoría de los paquetes no cambian entre versiones menores de KDE. Por ejemplo, al realizar una actualización del 3.3.1 al 3.3.2, apenas cambian alrededor de 100 de los 320 paquetes. Los paquetes separados nos permiten crear nuevos ebuilds solamente para aquellos paquetes que realmente cambian, ahorrándonos (en este ejemplo) más de dos tercios del tiempo en compilación en la actualización.
• Los parches usualmente afectan a un paquete en particular. Con los ebuilds separados, pueden ser probados y realizar un commit de ellos más rápido, y los desarrolladores tienen menos cosas para hacer; y como en el ítem anterior, el usuario se ahorraría tiempo en compilación al actualizar el KDE. En particular, esto es muy importante para las actualizaciones de seguridad.
• Los usuarios de otros entornos de escritorios y administradores de ventanas más sencillos, pueden instalar vía emerge las aplicaciones que quieran sin necesidad de instalar todas las demás aplicaciones de, por ejemplo, kdebase o kdepim.
• Los usuarios tienen un control más detallado con respecto a los paquetes que tienen instalados. Las razones por las cuales querrá esto son:
  • Le importa el tiempo de compilación. emerge kdebase kdepim kdenetwork tarda demasiado tiempo cuando lo único que necesita es konqueror, kmail y kopete, aparte la consideración que el tiempo es dinero ... en alguna parte.
  • Le importa el uso del espacio en el disco. Cada paquete no usado, malgasta muchos megabytes, "tapando los poros" del disco. Un disco con más espacio libre puede "respirar mejor"; es un disco rígido feliz :).
  • Le importa la seguridad de su sistema. Todo el software instalado es una fuente potencial de vulnerabilidades, y no existe excusa alguna para andar teniendo software por ahí en su sistema sin ser usado.
  • Es fiel adherente de la Filosofía Gentoo y no soporta el hecho que muchos programas estén en un enorme paquete forzado sobre los usuarios. Nosotros tampoco lo soportamos.
• Finalmente, los ebuilds separados también nos permiten más flexibilidad con respecto al tiempo de compilación y el uso de los parámetros USE.

Interoperabilidad entre los ebuilds separados y monolíticos

Los ebuilds monolíticos y separados pueden ser mezclados libremente. La única restricción es que un ebuild monolítico no puede ser instalado al mismo tiempo que un ebuild separado derivado de este. Existen dependencias bloqueantes en los ebuilds que hagan esto, así que sólo podrá hacer cualquier cosa que emerge le permita.

Sin embargo, por lo general, no existe razón alguna para utilizar una configuración mixta. De hecho, excepto en casos especiales, como que la compilación tarde demasiado (CPUs mips), debería utilizar los ebuilds separados.

Los ebuilds separados son los ebuilds por defecto. Esto significa que cuando otro ebuild dependa de una aplicación de KDE, querrá instalar un ebuild separado. Sin embargo, el ebuild monolítico equivalente también cumpliría con la dependencia, de manera que puede realizar un emerge del ebuild monolítico manualmente y luego realizar el emerge del ebuild que depende del mismo.

2.  Inconvenientes de rendimiento

¿Por qué los ebuilds separados son lentos?

Se ha dicho que debido a la sobrecarga de descomprimir y ejecutar 'configure' por cada paquete los ebuilds separados tomarán mucho más tiempo en realizar un emerge que los monolíticos. Un emerge kde-meta podría tomar un 20-30% más que el clásico emerge kde, lo cual es inaceptable debido al ya largo tiempo de compilación.

Además, en este momento los ebuilds separados siempre ejecutan make -f admin/Makefile.cvs (esto significa ejecutar autoconf, automake, etc. y demás guiones relacionados a KDE). Esto añade una tardanza adicional aproximadamente del mismo orden que demora al ejecutarse 'configure'.

Finalmente, un ebuild separado necesita extraer archivos específicos desde un archivo tar grande. Esto es más lento que realizar la extracción desde un archivo tar pequeño y dedicado. No obstante, crear archivos tar pequeños para el sistema de construcción basado en autotools del KDE 3.X es difícil.

Vale la pena reiterar que con los ebuilds separados, el tiempo de actualización de KDE puede ser considerablemente reducido con el simple hecho de realizar una actualización de los paquetes que realmente cambian. El beneficio de una actualización única por lo general hace que valga la pena pasar por la sobrecarga inicial de la instalación.

Finalmente, instalar todo el KDE tiene sentido si quiere explorar los paquetes disponibles o si está configurando un entorno multi-usuario; sin embargo, la mayoría de las personas utilizan sólo algunas de las más de 300 aplicaciones disponibles de KDE. Cualquier persona a quien le importe el tiempo de compilación, como los usuarios que poseen máquinas viejas, pueden ganar mas tiempo seleccionando solamente los paquetes que quieran.

¿Que se hará para acelerar los ebuilds separados?

La mayor parte o incluso todos los problemas de rendimiento de los ebuilds separados se relacionan a autotools - autoconf, automake y otras herramientas que gestionan el sistema de construcción ./configure;make;make install usado en KDE 3.x.

KDE 4 ha adoptado un sistema completamente nuevo de construcción, cmake, el cuál entre otras cosas reduce de gran manera el tiempo, y es equivalente a realizar un make -f admin/Makefile.common; ./configure

3.  PFU (FAQ) de los ebuilds separados

¿Por qué hay algunos paquetes separados que les faltan las versiones de ebuilds más nuevas?

Como explicamos arriba, no todas las aplicaciones son verdaderamente actualizadas entre versiones menores de KDE, así no todas las aplicaciones tienen nuevas versiones de ebuild. Por ejemplo, libkdenetwork no fue actualizado en 3.5.0_beta2, de forma que el último ebuild disponible con aquella versión fue 3.5_beta1.

Este se hace meramente para reducir el tiempo de compilación durante una actualización. Si hubiéramos hecho un ebuild libkdenetwork-3.5.0_beta2, este habría instalado precisamente los mismos archivos que el ebuild 3.5_beta1. Las varias dependencias son actualizadas para funcionar correctamente (es decir, no habrá ebuild alguno que dependa de libkdenetwork-3.5.0_beta2).

Note que a causa de ésto, si desea instalar versiones enmascardas de KDE, podría también necesitar desenmascarar paquetes de versiones anteriores de KDE, si es que están enmascaradas. Puede que le sea de utilidad leer éste bug para mayor información.

Actualmente, ¿no se puede hacer esto con DO_NOT_COMPILE?

DO_NOT_COMPILE es una variable de entorno interna que usa el sistema de construcción de KDE. Permite seleccionar los subdirectorios que no queremos que se compilen. Algunas personas lo usaban para compilar un subconjunto de los ebuilds monolíticos del KDE. Por ejemplo, si ejecutamos DO_NOT_COMPILE=konqueror emerge kdebase, entonces instalaríamos kdebase sin la aplicación konqueror.

Sin embargo, DO_NOT_COMPILE nunca fue diseñado para interferir con la operación alguna con el sistema de administración de paquetes, en particular, Portage. No funciona, puede romper su sistema y jamás fue soportado. Les pedimos a todos que desistan de su uso.

Aquí se detalla una lista parcial de los problemas que ocasiona DO_NOT_COMPILE:

• Rompe completamente con el sistema de localización de dependencias de Portage. Portage no sabe nada acerca de DO_NOT_COMPILE, y piensa que el paquete monolítico entero fue instalado y puede satisfacer una dependencia de otro paquete. Esto puede causar que otros paquetes no puedan ser instalados o que no puedan ejecutarse.
• Obliga al usuario a saber acerca de los nombres y significados de todos los subdirectorios de los módulos del KDE. Muy pocos usuarios saben acerca de esto, y a menos que sean desarrolladores de KDE, no saben utilizar DO_NOT_COMPILE apropiadamente.
• Los módulos de KDE pueden tener interdependencias entre ellos y requieren de un orden en particular para poder ser construidos, también requieren que otro subdirectorio se encuentre presente incluso si no es necesario instalarlo. En este aspecto, hemos puesto mucho trabajo en los ebuilds separados, de manera que funcionen correctamente. DO_NOT_COMPILE no se acerca ni un poquito para poder ser una herramienta que consiga los mismos resultados que los ebuilds separados, incluso si se le diera suficiente información al usuario para poder usarlo. La única cosa que hace es deshabilitar la compilación de un par de aplicaciones. Es prácticamente imposible que sea utilizado para seleccionar la instalación de determinadas aplicaciones de los módulos como kdebase o kdepim.
• Si ayer instalé kmail y hoy quisiera agregar korn, utilizando DO_NOT_COMPILE, nos llevaría a compilar a kmail nuevamente. Esto significa que DO_NOT_COMPILE siempre será mas lento que los ebuilds separados.
• DO_NOT_COMPILE no puede ser usado para realizar paquetes precompilados (como el GRP) conteniendo aplicaciones individuales del KDE.

¿No estarán colocándole demasiada carga a los mantenedores de Gentoo KDE?

Sorpresivamente, ésta es una pregunta que siempre hacen. Estamos halagados que los usuarios sean tan considerados con nosotros los mantenedores. Pero permítanos aprovechar esta oportunidad para decirles que nosotros estamos haciendo esto por nuestra propia voluntad; que creemos que podremos continuar manteniendo los ebuilds con una buena calidad; y que nadie nos podrá convencer que dejemos de hacerlo.

Por completitud, mencionamos que los mantenedores de otras arquitecturas se han quejado por el gran aumento de trabajo que les toma realizar verificaciones y modificaciones a tantos ebuilds separados. Estamos trabajando para resolver esto y cabe aclarar que esto fue una de las grandes razones por las cuales existen todavía ebuilds monolíticos para el KDE 3.5.

¿Van a borrar los ebuilds monolíticos?

Tenemos la idea de, eventualmente, borrarlos. Sin embargo, existen ebuilds monolíticos y separados para las todas versiones de KDE 3 hasta la 3.5.9. Para KDE 3.5.10 y posteriores y para KDE4 ya no proporcionamos ebuilds monolíticos.

Si prefiere utilizar los ebuilds monolíticos por sobre los separados, por favor, cuéntenos sus razones.

¡Hay tantos ebuilds!, ¿Cómo se supone que voy a encontrar los que necesito?

Bueno, primero que nada, si sabe que el paquete que está buscando se encuentra en kdebase, entonces puede, todavía, ejecutar emerge kdebase-meta, con casi los mismos resultados que si hubiese realizado un emerge del ebuild monolítico kdebase. Así que, en realidad, las cosas no han empeorado para nada debido a la introducción de los ebuilds separados.

Obviamente, siguen vigentes todas las maneras de localizar un paquete. ¿Cómo encontraría su ebuild si fuese una aplicación de Gnome?. Mínimamente debería de saber, por lo menos, el nombre de la aplicación que estas buscando.

Tal vez, la situación podría ser mejorada con la introducción de varios paquetes -meta. Solamente son listas de dependencias, así que no nos costaría nada. Esto todavía no ha sido decidido. Sin embargo sería bueno tener la funcionalidad de conjuntos en Portage antes de hacer esto en extenso.

¿Cómo puedo listar y/o realizar un unmerge de todos los ebuilds separados derivados de un paquete dado?

El objetivo aquí es el de listar todos los ebuilds de KDE derivados de, por ejemplo, el ebuild monolítico kde-base. Una vez más, una implementación apropiada (como GLEP 21) haría de esto algo trivial. Sin embargo, hoy, tiene que entender en cierto grado la implementación de las eclasses de KDE. Así que, si usa alguno de estos métodos en un guión que no sea para uso personal, por favor cuéntenos.

kde-functions.eclass define las funciones llamadas get-parent-package() y get-child-packages() que llevan a cabo la "traducción". Estas dos funciones son la manera correcta de completar satisfactoriamente este trabajo a partir de un ebuild o de un guión de bash externo. Aquí le mostramos un ejemplo:

$ function die() { echo $@; } # se llama para reportar errores
$ source /usr/portage/eclass/kde-functions.eclass
$ get-parent-package konqueror # no va a funcionar, tiene que especificar el
nombre completo
Package konqueror not found in KDE_DERIVATION_MAP, please report bug # el error es mostrado en la salida
$ get-parent-package kde-base/konqueror # nombre completo del paquete
kde-base/kdebase # el resultado es mostrado por pantalla
$ get-child-packages kde-base/kdebase
 # (una enorme lista de paquetes mostrado aquí)

Si su guión no está escrito en bash, puede realizar un grep del kde-functions.eclass para extraer la definición (multilínea) de la variable KDE_DERIVATION_MAP, que las funciones mencionadas usan. Esta variable contiene una lista de palabras separadas por un espacio en blanco; y cada par de palabras consecutivas realizan un mapeo entre un paquete "padre" a un hijo ebuild separado.

El contenido de este documento está registrado bajo los términos de la licencia Creative Commons - Reconocimiento / Compartir Igual