>> Miguel Gil <[EMAIL PROTECTED]> writes:
> �Para cuando se publicar� la debian 2.2? �Para el verano?
Siguiente versi�n de Debian: potato. Si se llama o no se llama
Debian 2.2, no est� decidido.
> -�Xfree 3.3.x?
S�, ya hay paquetes prob�ndose.
> -�kernel 2.2.x?
Err... no s� honestamente. Debian 2.1 funciona con el kernel 2.2,
pocas son las cosas que no lo hacen.
> -�postgres 6.5?
no s�.
> -�samba 2.0?
es probable.
> -�kde 1.1?
si cambian su dichosa licencia, s�.
> -�una distribuci�n de gnome decente?
[ omitir� el comentario sobre el adjetivo ]
Ya hay paquetes para GNOME 1.0.x (creo que x = 6)
> -�Incluir� el famoso sustituto del dselect?
�Qu� es la fijaci�n con esto? A lo mejor, a lo mejor no. Hay varios
funcionando, as� que la posibilidad existe.
> -�mozilla?
Preg�ntale a la gente de Mozilla, no a Debian. Hay paquetes para
mozilla en slink.
> -�esta pensado para funcionar con 4mb? �Sigue habiendo disquetes
> de instalaci�n para sistemas con 4mb de ram?
Entiendo que Debian 2.1 arranca en estas condiciones, no veo por qu�
la situaci�n pueda cambiar.
> -Se supone que debian 2.0 se retras� tanto, por que hab�a
> migrar de libc
correcto.
> hab�a que portar debian a varias arquitecturas
`hab�a que' es un poco exagerado.
> y tambi�n por que se necesitaba un sustituto decente al dselect y
> sin embargo no sali� ning�n sustituto al dselect
otra vez, `necesitaba' es un poco exagerado.
> -�por que casi todas las versiones de debian suponen un cambio
> dram�tico?
es la velocidad a la cual la comunidad se mueve. En potato se ha
introducido glibc 2.1, lo cual supone un trauma menos severo que la
introducci�n de glibc 2.0. Adem�s, la versi�n de Sparc de Debian 2.1
_ya_ utiliza glibc 2.1, as� que algunas de las cosas ya han sido
probadas.
Debian es un proyecto de voluntarios que trabajan en lo que les
gusta. En el momento que deje de gustarles, dejan de trabajar. Yo
he experimentado en carne propia lo que es quemarse con un paquete:
simplemente ya no te quedan ganas de seguir trabajando. Fuera del
proyecto tambi�n he visto a algunos desarrolladores perder el gusto
por lo que hacen pues por una raz�n u otra deja de ser divertido (por
ejemplo, cuando la gente comienza a _demandar_ que se hagan cosas)
> �no se podr�an sacar versiones que simplemente supusieran una
> actualizaci�n de los paquetes.
S�, se podr�a. Se ha discutido varias veces en debian-devel. La
pregunta siempre es �a qu� grupo de desarrolladores le gustar� ese
proyecto?
> Un problema muy gordo en debian, es que si tienes la versi�n 2.0 y
> quieres la �ltima versi�n de un paquete y resulta que est� esta
> preparada para la debian 2.1, puede que no puedas actualizar sin
> actualizar toda la debian.
Perd�n, pero pongo en duda eso. S� un paquete depende de algo, debe
declarar esa dependencia. Si no la declara, es un `bug.' Por
ejemplo, wmaker depende de `debianutils (>= 1.6)'. Esa dependencia
est� all� por un motivo, y seguir� estando all� mientras el paquete
exista o yo cambie algo para eliminarla.
Ahora, si te refieres a los casos en los cuales cambiar una
biblioteca implica cambiar m�s de un paquete, bueno, eso es
diferente. Nosotros no controlamos lo que la gente de m�s arriba
hace. Si los desarrolladores de tal o cual biblioteca compartida son
suficientemente tercos como para cambiar la interface binaria sin
cambiar el nombre de la biblioteca, bueno, hay que tratar de
encontrar una soluci�n, pero nos enfrentamos a un predicamento: �cu�l
es la forma t�cnicamente correcta de hacer las cosas sin romper la
compatibilidad binaria con otras distribuciones?
> Para mi lo ideal ser�a comprar una distribuci�n una vez y poco a
> poco ir bajandome las actualizaciones de los paquetes que mas uso,
En la medida que existan programadores que gustan de explorar nuevos
territorios eso no va a ocurrir. "Se me ocurri� esto, hace tal y
cual cosa" "Nos gusta, �lo vamos a usar!" Ni modo, a recompilar
programas se ha dicho.
> -�Para cuando se podr� debian de acuerdo con el resto de
> distribuciones en un sistema de paquetes com�n, en una
> organizaci�n del sistema de ficheros com�m, etc?
Otra vez: �cu�l es la soluci�n t�nicamente correcta para un problema
particular?
Muchos piensan que el formato .deb _es_ la soluci�n correcta. Nadie
va a dejar botado el formato de paquetes as� como as�.
> �Tan dificil es? �Es que realmente las diferencias merecen la pena?
> Se supone que somos distintos a windows, en windows cambias de
> windows 3.1 a windows 95 y te dejan de funcionar las cosas, a este
> paso creo que lo mismo nos pasar� al pasar de debian a redhat, de
> redhat a suse, etc.
La diversidad es riqueza. Mientras existan opciones, Linux ser� un
proyecto viable. En el momento que las opciones no existan, Linux
deja de existir como lo conocemos. Utilizar un formato de paquetes
com�n no es tan inconcebible, pero tampoco es tan f�cil como suena.
Marcelo
