Barrapunto

No lo sé en el caso de los paquetes .deb, pero en los rpm's hay una pesadilla: la manía de dar distintos nombres a las mismas bibliotecas... si yo tengo ya instalada, pongamos "perl-ldap", por qué puñetas me chilla una aplicación porque depende de "Perl-LDAP".

Esto no es vida.... pero desde luego, la solución propuesta es todavía peor... tiemblo al pensar: cada fichero del /usr/bin/ con su propia copia de la libc....

btw: "ls /usr/bin | wc -l" da en mi bicho 2856 ejecutables...

... Algún día....

.

"la respuesta es simple, pásate a debian"

¿A qué debian? ¿Ubuntu? ¿Molinux? ¿Guadalinex? ¿Lliurex? ¿Linex?. Cada vez que lo he intentado con mi portátil [dit.upm.es], he tenido que tirar la toalla...

Utilizando "yum" con los rpm's oficiales, y los de dag, freshrpms y pbone.net nunca hay problemas. Solo cuando hay que hacer búsquedas raras salen esas incompatibilidades... y en ese caso "configure; make; make install" hacen maravillas

¿Falló porqué? El cambio de número de versión indica que las librerías no tienen una API compatible así que un programa programado con la API de librería 1.2 de, por ejemplo GTK, no va a compilar con versiones de librería 2.x.

Esto no va por tí pero cada vez se ve a más novatos que vienen de Windows y no ven que en aspectos de versionado de librerías e instalación de programas Linux está muy lejos por delante de Windows. Por favor, en vez de cerraros a lo que conoceis intentar ver porqué en Unix las cosas se hacen como se hacen porque normalmente es una forma muy buena de hacer las cosas.

Otro caso en el que la forma de hacer de Unix gana de calle es en los programas que tienen un demonio con el que se comunica el programa cliente. Así el núcleo del programa no necesita de las X, te puedes conectar con diferentes programas y cuando no estás delante del PC puedes prescindir del modo gráfico sin tener una ventana dando el coñazo. Un ejemplo MLDonkey.