Grzegorz Adam Hankiewicz wrote:

> On Tue, 9 Jan 2001, salvador wrote:
> > > Si, pero, ¿obligará a bajarse todas las librerías soportadas?
> > ...
> > Ese mecanismo puede servir: generás 2 paquetes, uno con soporte de SVGAlib y
> > otro sin, los dos los ponés mutuamente exclusivos (hacen conflicto entre
ellos)
> > y punto.
> > Tenés que evaluar cuales opciones vale la pena separar y con eso decidir
cuantos
> > paquetes armar.
>
> Ya, y ahí es donde "nunca llueve a gusto de todos".
>
> > ¿Cuáles? repasemos las cosas, ¿qué librerías necesita Allegro?
> >
> > 1) SVGAlib
> > 2) Algo de GGI
> > 3) Xlib
> > 4) Librerías de DGA
> >
> > El 3 y 4 van de la mano. En mi Potato las librerías de DGA parece que las
> > instaló con el X.
>
> En la mía no :) porque instalé X a mano, explícitamente.

¿Y cuál es el problema?

> Además, te
> olvidas de framebuffer, que creo que incluso necesita las cabeceras del
> núcleo (y yo estuve tuviendo unos cuelgues muy majos por tener cabeceras
> obsoletas con un núcleo nuevo, así que incluso dependencia del núcleo...).

Estas hablando de lo que sería liballegro-dev. Yo te hablo de lo que necesita
instalar un usuario.
Ese problema se resuelve *muy* simplemente, "liballegro-dev depende de
kernel-headers". En Debian la forma correcta de instalar tu propio kernel es
instalar
un paquete que se llama kernel-package. Con esto vos creas un paquete para el
kernel
que luego instalás. ¿Cuál es la ventaja? Varias:
1) Ese paquete contiene los módulos adecuados.
2) Tu sistema dre paquetes sabe que kernel tenés.
3) dpkg se encarga de que lilo bootee el nuevo kernel y de que tengas
posibilidad de
bootear el anterior.
4) Podés instalarlo en varios sistemas o usarlo como back-up de manera muy
simple.
5) Lo que viene al caso: mantenés la coherencia de los headers porque uno de los
paquetes que generás es kernel-headers.

Por lo que .... usando una Debian no tendrías ese problema ;-)))

> > Si usás el 1 no usas el 2.
>
> No necesariamente: con GGI puedes usar framebuffer o aalib como salida
> final y pasar de SVGAlib (que en mi ordenador funciona a patadas).

Hmmmm.... un tercer paquete.

> > Soporte para X es "mandatory".
>
> Seré un caso raro, pero sigo usando equipos de gama ultrabaja que no
> tienen X (más que nada porque da pena ejecutar X en esos bichos :-) Aunque
> obviamente en esos no les voy a meter paquetes precompilados, y compilar
> Allegro se asemeja a compilar el núcleo.

:-))), si, si no querés tener ni un byte de más en tu sistema podés hacerlo,
pero las
librerías básicas de X no son tan gigantes.
Las librerías de X *no* dependen del X propiamente dicho ni de ninguna de sus
cosas.

> > allegro-demo, depende de: liballegro, libc6, libesd o libesd-alsa, libggi,
> > svgalib y xlibs.
>
> Pues ahí ya la he fastidiado: no tengo ni esd ni alsa.

No es cuestión de que tengas o no. Me parece que no captás la idea de los
paquetes:
un paquete depende de otro => apt-get/dselect instalan el otro paquete. No es
que lo
tengas o no, te obliga a que ese paquete se instale en tu sistema. ESD puede
instalarse sin el hardware adecuado (sin placa de sonido).

> > Pero por supuesto que es decisión de Eduard Bloch <blade@...>.
>
> Mala suerte la de ser empaquetador: es difícil tarea; yo al menos no me
> atrevería, tantas posibilidades...

Es que lo ves de una forma incorrecta. Si querés usar una 386 con 300 Mb de
disco no
vas a instalar una distro moderna. ¿Por qué? porque el kernel, compilador,
herramientas, etc. actuales literalmente matan una 386. En una 386 con 8 Mb de
RAM yo
no usaría un bash, etc.
Si vas a instalar Woody con Allegro es porque probablemente lo hagas en una
máquina
decente que tiene al menos 600 Mb de disco. En esas condiciones verte forzado a
"mal
gastar" unos Mb de disco por instalar un juego que usa Allegro no es demasiado
sacrificio.
Hay varios paquetes con dependencias de este tipo, veamos GNU plot:

Depende de:
debconf
Debian configuration management system
libc6 (>= 2.1)
GNU C Library: Shared libraries and Timezone data
libpng2
PNG library - runtime
zlib1g
compression library - runtime
svgalibg1
SVGA display utilities
or svgalib-dummyg1
Dummy replacement for svgalib1
xlib6g (>= 3.3.5-1)
shared libraries required by X clients

Sugiere:
suidmanager
Manage File Permissions

Como verás es imposible instalar GNU plot sin instalar las librerías de X.
Lo interesante es que podés instalar svgalib-dummyg1 en lugar de la verdadera,
Eduard
debería seguir este ejemplo (ya le mandé un mail avisándole ;-).

> Es perfectamente posible hacer los paquetes. En cualquier caso, seguiría
> siendo mejor desarrollar el soporte de carga dinámica de módulos para
> Allegro, y así la línea de dependencias de arriba supongo que cambiaría a:
>
> allegro-demo, depende de: liballegro, libc6.
> allegro-demo, sugiere: libesd-al, libesd-alsa-al, libggi-al, svgalib-al y
> xlibs-al
>
> O algo parecido. Las sugerencias quizás las haría liballegro, qué se yo.

Si, sería más liviano para algunos, aunque no te olvides que eso incrementa la
complejidad.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft@... set@...
set@...
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013