1. Los ebuilds separados de KDE
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.
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.
¿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:
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:
¿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.
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:
Listado de Código 3.1: Ejemplo de uso de las funciones de kde-functions |
$ 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