Barrapunto

Lo condenso para no eternizar esta discusión:

1. No, aún no he visto en ningún lado que nadie diga nada sobre que ese ebuild estaba en la estable. Esas "pistas" no dicen nada al respecto, de ahí no se puede deducir que estuviese en la estable. Y el discurso de la "seriedad" está fundamentado en esto (que, por cierto, débil argumento aunque se probase cierto, teniendo en cuenta su antigüedad y que de momento no ha llegado al oído otro "caso").

2. Sobre el tema de la organización de la gente en Gentoo: lo que yo ví (en "hardened") fue todo lo contrario. Que pueda ocurrir en lo que tú viste, perfecto. ¿Se puede asegurar que un pequeño grupo no se comporte de forma similar en Debian?

3. JDK/JRE: blackdown es libre e instalable. Igual que en Gentoo se tiene un virtual/x11 equivalente a x-window-system (no, no hacía falta que explicaras eso, ni lo de que Gentoo no inventó lo de compilar, ni lo de las webapps, me da la sensación de que crees que no hay gente de "nivel" en Gentoo...), se tiene uno (con el concepto de "slots") para el JDK. Como ya dije, en Gentoo no hay problema.

4. Eso si, en Debian unstable si que estoy acostumbrado a cosas como las que comentas.

Pues eso es de lo que iba mi post principal, y que cualquiera puede comprobar, tanto en una como en otra, si dan o no problemas.

5. ¿Busco yo los bugreports de esos errores de sintaxis en los DEB en el bugzilla de Debian? Si estan, dudo que sean a tu nombre

Se perdieron los errores entre los cientos de líneas de paquetes configurándose. :S De todas formas ya pongo mis granitos de arena en otros rincones del desierto y no hay tiempo o ganas para todo.

6. el principal programa de mantenimiento del sistema debería dar la información al usuario de un modo útil, no esperar que sea el mismo el que se busque la vida generando y mirando logs.

Ni que buscársela por errores que hubo en los .DEB ni buscársela para tener un JDK. :)

7. que una distribución no se lleva desde un foro

Esa es la actitud o culturilla "conservadora" basada en "axiomas" totalmente _falsos_ que ha creado escuela entre muchos administradores de sistemas/redes y usuarios de algunas distribuciones. Dime, ¿quién dice que una distribución "no se lleva" desde un foro? ¿Es esto como el concepto de "seriedad"? Dos cosas te digo: la primera, un "foro" es un medio más de comunicación perfectamente válido y, como se ha demostrado, más que eficaz especialmente de cara a los usuarios, y la segunda, en Gentoo también saben lo que son los servidores de correos, las listas de correo y los gestores de bugs, como bien sabes.

8. (y último) Al final, la cuestión inicial, mostrar que efectivamente hay bastantes problemas con sid ha quedado clara. Lo mismo sobre Gentoo queda para otra vez que alguien -ya que tú no quieres- quiera hacer la prueba, y compare los resultados.

En definitiva, y con esto doy por terminado el hilo por mi parte (salvo que creas conveniente añadir más y yo no pueda aguantarme la respuesta :), a ti te va muy bien y yo no te voy a hacer cambiar de idea, y lo mismo en cuanto a mí. Pues nada, cada uno a disfrutar lo suyo sanamente.

No, aún no he visto en ningún lado que nadie diga nada sobre que ese ebuild estaba en la estable. Esas "pistas" no dicen nada al respecto, de ahí no se puede deducir que estuviese en la estable.
ChangeLog del ebuild de Squirrelmail [gentoo.org] :
*squirrelmail-1.4.1 (08 Jul 2003)
...
28 Jun 2003; Martin Holzer
squirrelmail-1.4.0-r1.ebuild:
removed apache grep stuff.

*squirrelmail-1.4.0-r1 (29 Apr 2003)
21 May 2003; Martin Holzer
squirrelmail-1.4.0-r1.ebuild:
Marked stable on x86.

Más fácil ya no lo puedo poner. Si con esto no se hace evidente que efectivamente *si* estaba marcado estable, yo ya no sé que más hacer, lo siento. Por otro lado: en *este* caso se corrigió porqué puse un bugreport, pero tengo la intuición de que en muchos otros paquetes esto no se corrigió hasta que estos se adaptaron al plugin webapp del portage.

Y el discurso de la "seriedad" está fundamentado en esto (que, por cierto, débil argumento aunque se probase cierto, teniendo en cuenta su antigüedad y que de momento no ha llegado al oído otro "caso").
No está fundamentado en eso. Ese hecho en si, fuera de contexto, es una anécdota informática como cualquier otra. Sin embargo, es el más claro ejemplo de los peligros que entrañan la naturaleza y la estructura de desarrollo de Gentoo. Si ésta ha cambiado o no, no es algo que yo sepa ni me importe en exceso en este momento. Si tu aseguras que sí, y que el equipo de QA se ha hecho fuerte, me alegro.
La propia naturaleza tecnológica de Gentoo implica cierto "elitismo" de sus desarrolladores. Maximizar las variaciones posibles (useflags, cflags, dependencias "blandas" por poder linkar versiones distantes de las mismas librerias, etc..) significa maximizar la posibilidad de problemas y la dificultad de reproducirlos y depurarlos. Y ser capaz de manejar esto convenientemente no es lo mismo que ser capaz de escribir un ebuild o construir un paquete DEB. Si encima no hay unas "Guidelines" concretos y "Policies" estrictos, la cosa se sale de madre con una facilidad inaudita. No dudo que los desarrolladores del core de Gentoo, así como algunos de la "periferia", tengan la capacidad y conocimientos suficientes. Lo que pongo en seria duda (y confirmo por lo que he visto) no es solo que la mayor parte de desarrolladores carezcan de la capacidad y/o conocimientos para ello, sinó incluso que sean conscientes de donde se están metiendo y de con cuantas variables están jugando. Por esa razón en Debian existen tantas reglas (estúpidas para muchos): para que la mayor parte de esas variables se conviertan en constantes y el problema sea manejable.

Sobre el tema de la organización de la gente en Gentoo: lo que yo ví (en "hardened") fue todo lo contrario. Que pueda ocurrir en lo que tú viste, perfecto. ¿Se puede asegurar que un pequeño grupo no se comporte de forma similar en Debian?
Supongo que los desarrolladores del GLEP hardened serían lo suficientemente avanzados como para coordinarse bién entre ellos y no cometer errores garrafales; la propia naturaleza del subproyecto implica esas características. Tampoco dudo de la sobrada capacidad del "core" de desarrolladores de Gentoo; no se monta una distribución semejante sin unos buenos conocimientos ni capacidad de coordinación. A lo que me refiero es que se aceptan (o aceptaban) paquetes de cualquier usuario sin una revisión en profundidad. Por la estructura del portage, un "inocente" bug en un ebuild puede causar estragos en el sistema (aunque se use el sandbox), y por lo tanto estos deberían revisarse en profundidad. Puedo entender que falten recursos humanos y paciencia para ello, o que el proyecto esté algo verde, pero no que se niegue uno de los principales problemas de la distribución. Tal como leí en alguna firma: "When you are on the cutting edge you WILL