Re: [gentoo-user-es] organizando los programas que tengo instalados

[Arnau Bria]

On Thu, 7 Dec 2006 11:27:30 +0100
Javier M Mora wrote:

> 2006/12/7, Arnau Bria <arnau@×××××××××.net>:
> > On Wed, 6 Dec 2006 11:09:45 +0100
> > Javier M Mora wrote:

> Fíjate que hablo de nuevos programas, no de nuevas versiones.
> Simplemente quería decir que ya no necesito instalarme el sodipodi
> para saber de que va.
Si, perdona...  

[...]
> >
> > De todos modos, creo que es más complicado de lo que parece, porque
> > mantener varios "worlds" se puede complicar cuando las dependencias
> > estén repetidas en varios archivos, [...]
>
> Bueno, no son exactamente varios worlds. Yo lo veo más como un único
> world dividido en varios ficheros. A la hora de procesarlos se
> interpreta como un único fichero, pero físicamente están separados por
> temas o areas.

Si, bueno, no sabía como referenciarlo, pero entiendo tu idea, sólo que
lo llamo varios worlds... Pongamos un ejemplo, para
aclarar, yo quiero instaar beryl, todo lo que me instale (dependencias
incluidas) irían a parar a un fichero llamado ~arnau/portage/beryl, por
ejemplo, ok?


> [Hasta donde yo se (HDYS)] En el fichero world no están todos los
> paquetes instalados en el sistema, ni hay relación de dependencias.
> Sólo están los ficheros que el administrador ha instalado manualmente
> con un emerge. Todo paquete instalado que no aparezca en el fichero
> world es una de dependencia.

Eso es. 
i.e: wc- l: 120 /var/lib/portage/world
 
> (HDYS) Al parecer no existe ningún fichero que guarde las dependencias
> entre paquetes, de hecho en cada emerge, el primer mensaje es siempre
> "Construyendo las dependencias".

exacto.

> así que por este camino, habría que añadir a emerge una opción que
> indicase el "area" (¿continente? ¿pais?, el que más me gusta es
> región) donde se instalará un programa. (dejando por defecto world) y
> que todas las utilidades que usan el fichero world, enlacen con su
> contenido todas las regiones que estén disponibles.

Mmmmm... esto lo veo más complicado. 

> Creo que es una solución sencilla y menos complicada de lo que
> comentabas aunque hay que tocar en el código del sistema de portage.

Por eso lo veo más complicado. Además de tener que refenciar todos los
paquetes con sus regiones...
 
> > Repito, la idea me gusta.
>
> Estupendo. Solo necesito a un patrocinador generoso. :-)
>
> La otra idea, que no mencionas, es incluso más sencilla de implementar
> y creo que voy a usar. Recuerdo para el que no tenga ganas de subir en
> el hilo: cuando se instala un paquete se añade "un texto que incluya
> una razón" y todos los paquetes instalados y sus dependencias quedan
> marcadas con dicha razón. En cualquier momento podemos saber porque
> cierto paquete se instaló hace ya.... 3 largos meses y borrarlo o
> mantenerlo según nos interese.
>
> La implementación será: incluir el fichero world (situado en
> /var/lib/portage/world) en un sistema de control de versiones. RCS
> puede valer estupendamente para un fichero.
>
> El siguiente paso sería escribir un wrapper de la utiliddes de portage
> que exigiesen un texto de explicación. Se efectuaría el emerge (o lo
> que correspondiese) y se guardaría la nueva versión enlazado con la
> explicación.
>
> Para saber porque se instaló un programa, solo hay que ver el arbol de
> cambios en el word y la explicación en aquel momento y actuar en
> consecuencia.

Bueno, tomando de ejemplo el script en bash que comentaba, veo más
sencillo que se genere un nuveo fichero llamado beryl (siguiendo el
ejemplo de antes) que contenga beryl-manager y sus dependecias (si las
tiene, que habalos de un ejemplo)... Y si queremos añadir más cosas
(por ejmplo, x11-misc/emerald-themes) tener la posibilidad de meterlo
en fichero beryl ya creado.

Ahora bien, a la hora de borrar, habría que comprobar que las
dependencias instaladas no las necesita nadie más. Ejemplo:

#emerge -puDt beryl-manager

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[nomerge      ] x11-misc/beryl-manager-0.1.2
[ebuild     U ]  x11-libs/gtk+-2.10.6 [2.8.19]
[ebuild     U ]   x11-libs/pango-1.14.7 [1.12.3]
[ebuild     U ] x11-terms/xterm-222 [218]
[nomerge      ] media-fonts/font-alias-1.0.1
[nomerge      ]   dev-libs/atk-1.12.1
[ebuild     U ]    dev-libs/glib-2.12.4-r1 [2.10.3]
[ebuild     U ]   x11-libs/cairo-1.2.4 [1.0.4] USE="pdf%* -directfb% -svg%"
[ebuild     U ]    media-libs/glitz-0.5.6 [0.4.4]
[nomerge      ]     virtual/opengl-7.0
[nomerge      ]      media-libs/mesa-6.5.1-r1
[nomerge      ]       x11-libs/openmotif-2.2.3-r9
[nomerge      ]        sys-libs/glibc-2.4-r4
[ebuild     U ]         sys-libs/timezone-data-2006p [2006o]
[ebuild     U ]         sys-kernel/linux-headers-2.6.17-r2 [2.6.17-r1]
[nomerge      ] app-misc/ca-certificates-20050804
[nomerge      ]  x11-apps/xlsclients-1.0.1
[nomerge      ]   x11-libs/libX11-1.0.3
[nomerge      ]    x11-proto/kbproto-1.0.3
[nomerge      ]     sys-devel/binutils-2.16.1-r3
[ebuild     U ]      sys-devel/binutils-config-1.9-r3 [1.9-r2]
[nomerge      ]     sys-devel/automake-1.9.6-r2
[nomerge      ]      sys-devel/autoconf-2.60
[ebuild     U ]       sys-devel/m4-1.4.7 [1.4.6]

Yo tendría esto en ~arnau/portage/beryl

Claro que al hacer un emerge beryl-amanger no tiene porque instalarme
gtk ni glibc (que ya tengo) pero si que puede que me haga un update,
con lo cual ese paquete irá a ~arnua/portage/beryl. Y al hacer el
remove debería comprobar que tanto glibc y gtk pueden ser borrados
porque nadie más lo utilizará... y eso es complicado (sino, te aseguro
yo que un emerge -C borraría las dependencias huérfanas)

Ese punto es el que veo más peliagudo.

Aunque si que se podría tomar una foto del world actual y el world tras
el emerge de beryl, y hacer un diff, así eliminaríamos los paquetes
updateados, y sólo nos quedarían los que hemos incluido nuevos...

> Y aquí terminó la divagación de hoy.
>
> > PD: mantenos informados del asunto :-)
>
> Si llego a alguna conclusión funcional, lo sabreis. Aunque eso puede
> que no llegue pronto.

Yo pasaría la idea por los foros, seguro que toma forma rápido y
encuentras a algún developer dispuesto a colaborar...

> atte. javier m mora (jamarier)
salu2,


-- 
Arnau Bria
http://blog.emergetux.net
Wiggum: Dispara a las ruedas Lou.
Lou: eee, es un tanque jefe.
Wiggum: Me tienes hartito con todas tus excusas.

-- 
gentoo-user-es@g.o mailing list