Attachment #68764 for bug #106398

View | Details | Raw Unified | Return to bug 106398
Collapse All | Expand All





<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">

<guide link="/doc/es/kde-split-ebuilds.xml" lang="es">

<title>El COMO (HOWTO) de los Ebuilds separados de KDE</title>

<author title="Autor">
  <mail link="danarmak@gentoo.org">Dan Armak</mail>
</author>
<author title="Editor Es">
   <mail link="chiguire@gentoo.org">John Christian Stoddart</mail>
</author>
<author title="Editor Es">
   <mail link="yoswink@gentoo.org">José Luis Rivero</mail>
</author>
<author title="Editor">
    <mail link="bass@gentoo.org">José Alberto Suárez López</mail>
</author>

</author>

<abstract>
Con el lanzamiento de KDE 3.4, se incorporaron a Portage los 'ebuilds
separados'. Esta página documenta las razones detrás de esta transición, las
nuevas funcionalidades brindadas por la misma y la forma de actualizar 
del viejo estilo de los ebuilds 'monolíticos'.
</abstract>

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>

<version>1.5</version>
<date>2005-07-02</date>

<chapter>
<title>Los ebuilds separados de KDE</title>
<section>
<title>¿Qué es lo que son?</title>
<body>

<p>
Hasta Enero del 2005, los únicos ebuilds de KDE en Portage eran los
'monolíticos'. Eso significa que solamente existían 15 ebuilds, 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, hasta hoy.
</p>

<p>
Los nuevos ebuilds 'separados' han rectificado esta situación, nos
proveen ebuilds separados para todas las aplicaciones de KDE. Esto nos da 
cerca de 330 nuevos ebuilds en la categoría kde-base.
</p>

<p>
Todavía se proveen ebuilds 'monolíticos' para KDE 3.4 e interoperan con los
'separados' transparentemente. Sin embargo, los ebuilds separados son el nuevo
valor por defecto, y no habrán más ebuilds monolíticos para cuando salga KDE
4.0.
</p>

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

</body>
</section>
<section>
<title>¿Cómo usarlos?</title>
<body>

<p>
En el momento de edición de este documento, la última versión de KDE es la 3.4.1,
la cual fue marcada como estable hace poco. En Portage se encuentran los 
correspondientes ebuilds separados y monolíticos.
</p>

<ul>
  <li>
    Para realizar un emerge de un paquete particular, como kmail, simplemente
    debe de escribir <c>emerge kmail</c>.
  </li>
  <li>
   Para realizar un emerge del entorno básico de KDE en donde pueda realizar
   login a una sesión minimalística de KDE, tiene que ejecutar <c>emerge
   kdebase-startkde</c>
  </li>
  <li>
    Finalmente, el equivalente a lo que realiza un ebuild monolítico (por
    ejemplo, para instalar todas las aplicaciones incluidas en
    <c>kdebase</c>) utilizando los ebuilds separados, debe de ejecutar
    <c>emerge kdebase-meta</c> (o kdepim-meta, etc.). Para instalar
    absolutamente todo el paquete KDE (usando ebuilds separados) ejecute <c>emerge kde-meta</c>
  </li>
</ul>

</body>
</section>
<section>
<title>¿Cómo actualizar a los ebuilds separados a partir de los monolíticos?</title>
<body>

<p>
Si tiene instalado KDE 3.3.x, puede simplemente ejecutar <c>emerge kde-meta</c>
para instalar los ebuilds separados de 3.4.x sin afectar su instalación existente.
</p>

<p>
Si tiene instalados los ebuilds monolíticos de KDE 3.4.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 continuación de otro sin tener que 
desinstalar todo KDE de una vez.
</p>

<p>
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.
</p>

</body>
</section>
<section>
<title>Ventajas de utilizar los ebuilds separados</title>
<body>



<ul>
  <li>
    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.
  </li>
  <li>
    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.
  </li>
  <li>
    Los usuarios de otros entornos de escritorios y administradores de ventanas más
    simples, pueden instalar vía emerge las aplicaciones que quieran
    sin necesidad de instalar todas las demás aplicaciones de, por ejemplo,
    kdebase o kdepim.
  </li>
  <li>
    Los usuarios tienen un control más detallado con respecto a los paquetes que
    tienen instalados. Las razones por las cuales pueda querer esto son:
    
    <ul>
      <li>
        Le importa el tiempo de compilación. <c>emerge kdebase kdepim
        kdenetwork</c> tarda mucho tiempo cuando lo único que necesita es
        konqueror, kmail y kopete.
      </li>
      <li>
        Le importa el uso del espacio en el disco.  Cada paquete que no es
        usado, malgasta muchos megabytes de su disco, "tapando sus poros". Un
        disco con más espacio libre puede "respirar mejor"; es un disco
        duro rápido y feliz :).
      </li>
      <li>
        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.
      </li>
      <li>
        Sigue fielmente la
        <uri link="http://www.gentoo.org//main/en/philosophy.xml">Filosofía de
Gentoo</uri> al hacer las cosas, y no soporta el hecho de que muchos
programas estén en un enorme paquete, forzándolo a instalarlos.
      </li>
    </ul>
  </li>
  <li>
    Finalmente, los ebuilds separados permiten más flexibilidad con
    respecto al tiempo de compilación y el uso de los parámetros USE (USE flags).
  </li>
</ul>

<p>
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.
</p>

<p>
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.
</p>

<p>
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.
</p>


<chapter>
<title>Inconvenientes de rendimiento</title>
<section>
<title>¿Por qué los ebuilds separados son lentos?</title>
<body>

<p>

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 <c>emerge kde-meta</c> podría tomar un 20-30%
más que el clásico <c>emerge kde</c>, lo cual es inaceptable debido al ya largo
tiempo de compilación.
</p>

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

<p>
A simple vista se puede observar que este análisis es meramente superficial y no
es muy detallado. Sin embargo, muchos de los factores causantes de esta ralentización, serán
detallados en las próximas secciones.
</p>

<p>
Vale la pena reiterar que con los ebuilds separados el tiempo de actualización
de KDE puede ser 2 veces mas rápido, y en algunos casos 10 o más veces,
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.
</p>

<p>
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 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.
</p>

</body>
</section>
<section>
<title>¿Que se hará para acelerar los ebuilds separados?</title>
<body>

<p>
La mejora más obvia sería distribuir archivos .tar.gz/tar.bz2 
(tarballs) para los ebuilds separados, evitando así el hecho de descomprimir
partes de los tarballs de los ebuilds monolíticos (kdebase, etc...) que son
distribuidos oficialmente. Esto eliminaría dos de los tres factores que influyen
en la sobrecarga del sistema: la repetida extracción de enormes tarballs y la
regeneración de los archivos makefile ( la etapa de <c>make -f
admin/Makefile.cvs</c> descrita arriba).
</p>

<p>
Esto nos deja solamente con el inconveniente de ejecutar repetidamente
 <c>configure</c>. La solución apropiada a este problema es confcache: es un
caché de configure que se comparte entre ejecuciones del emerge. Ya existe una
implementación en la rama de desarrollo de Portage (la herramienta, no el árbol
de paquetes); se espera una versión estable de confcache para dentro de
aproximadamente 6 meses.
</p>

</body>
</section>
<section>
<title>Otros factores que contrarrestan la ralentización de los ebuilds separados.
</title>
<body>

<p>
En la sección anterior se mencionan métodos para mejorar el rendimiento de los
ebuilds separados en particular. A continuación, mencionaremos algunas mejoras
que son igualmente aplicables a los ebuilds monolíticos.
Estas mejoras ayudan a que los ebuilds separados sean lo 'suficientemente
rápidos', exceptuando las comparaciones con soluciones menos peculiares como los
ebuilds monolíticos.
</p>

<ul>

    Todas las demás herramientas involucradas en la construcción serán aún mas
    rápidas con el pasar del tiempo, y consecuentemente los tiempos de
    compilación de varios paquetes relacionados con kde serán menores. La nueva
    funcionalidad de GCC 3.4 (visibility=hidden) y las cabeceras precompiladas (GCC 4.0)
    son dos ejemplos actuales. No son algo que uno gana debido al hecho de
    utilizar ebuilds separados; sólo significa que ahora podemos sobrellevar
    compilaciones que utilizan más la CPU.
  </li>
</ul>

<body>

<p>
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 
 <c>DO_NOT_COMPILE=konqueror emerge kdebase</c>, entonces instalaríamos a

</p>

<p>
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.
</p>



<ul>
  <li>
    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.

  <li>
    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. 
  </li>
  <li>
    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

    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.
  </li>
  <li>
    Si ayer instalé kmail y hoy quisiera agregar korn, utilizando

<body>

<p>
Sorpresivamente, ésta es una pregunta que siempre hacen. Estamos halagados que los
usuarios sean tan considerados con nosotros los mantenedores. Pero permitanos
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 a que dejemos de

</p>

<p>
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.4.
</p>



<p>
Tenemos la idea de, eventualmente, borrarlos. Sin embargo, existirán los
ebuilds monolíticos y separados para las todas versiones de KDE 3.4.
</p>

<p>
Si prefieres utilizar los ebuilds monolíticos por sobre los separados, por favor, 
<uri link="http://bugs.gentoo.org">cuéntenos</uri> sus razones.
</p>

</body>

<body>

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

<p>
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.
</p>

<p>
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.
</p>

</body>
</section>
<section>
<title>¿Cómo puedo realizar desinstalar (unmerge) de un KDE viejo?</title>
<body>

<p>
Supongamos que sale la versión 4.0 del KDE y quiere realizar un unmerge de
todos los ebuilds separados de KDE 3.4. Debido a que corresponden a diferentes
slots, el programa emerge no le permitirá hacer esto, así que se necesita hacerlo de otra forma.
</p>

<p>
Una solución a este problema requiere modificaciones a Portage. Una posible
solución se encuentra descrita en <uri
link="http://www.gentoo.org/proj/en/glep/glep-0021.html">GLEP 21</uri>. Sin
embargo, antes de que eso esté implementado, deberemos utilizar scripts como el

siguiente código funciona:
</p>

<pre caption="Borrando KDE 3.4 del sistema">
# <i>for x in `ls /usr/portage/kde-base`; do</i>
> <i>if [ "$x" != "CVS" ]; then</i>
> <i>echo -n "=kde-base/$x-3.4* "</i>

<body>

<p>
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 <uri
link="http://www.gentoo.org/proj/en/glep/glep-0021.html">GLEP 21</uri>) 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 script que no sea para uso personal, por favor cuéntenos.
</p>

<p>
kde-functions.eclass define las funciones llamadas get-parent-package() y
get-child-packages() que hacen la "traducción" para Ud. Estas dos funciones son
la manera correcta de completar satisfactoriamente este trabajo a partir de un
ebuild o de un script de bash externo. Aquí te mostramos un ejemplo:
</p>

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

<p>
Si su script 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.
</p>


Return to bug 106398