Barrapunto

No, porque la licencia no lo permite. De todas formas no hay página que explique qué instrucciones hay que seguir para instalarlo porque solamente es cuestión de bajarlo. Irse a una web a seguir ciertas instrucciones, que resulta que dependiendo de las versiones de las herramientas y de la rama de debian usada son diferentes, no entra en mi idea de mantenimiento fácil.
Que si, que el azul verdoso es completamente diferente del verde azulado. Pero la respuesta la das tu mismo en tu primera frase. Las JDK/JRE de SUN/IBM NO son libres, y por lo tanto no están en Debian oficial. Incluir un paquete específicamente diseñado para generar e instalar un paquete DEB a partir de ese JDK/JRE, para muchos es una manera retorcida de hacer exactamente lo mismo. Existen paquetes no oficiales para crear paquetes del JDK/JRE, y si los quieres usar con una búsqueda en Google acabas. ¿Podría hacerse de otra manera más fácil, o incluir esos "pseudopaquetes" en la distribución? Puede, y seguramente se ha discutido hasta la saciedad. Pero considerar su ausencia como un error o un problema de mantenibilidad, es desproporcionado.

Bueno, tú dices que sí y yo que no. Buscando un poquito, la utilidad que configura los paquetes webapp se propuso [gentoo.org] en agosto de 2003. ¿Alguna posibilidad de comprobarlo con más seguridad?
A ver si me explico esta vez. "Webapp" no es un término acuñado por Gentoo, ni por asomo. Es la abreviación de "Web Application", que se traduce por "aplicación Web". Y de éstas, había unas cuantas en portage. Y esos ebuilds eran los que usaban esa "temeridad", aún cuando lo más parecido al "responsable de servicios web" del núcleo de desarrolladores de Gentoo había dejado bastante claro que NO debía usarse nada parecido. Es más, instaba al autor de esa línea a contactar con cada desarrollador de un ebuild que usase esa línea para que la eliminase (eso es "unspam"). Pero esos paquetes seguían colando en portage como estables sin homogeneización, inspección o control de calidad alguno. ¿Se me entiende ahora?
Y si quieres, puedes negarlo tanto como quieras, pero ERA ASI. ¿Te has mirado los bug reports? ¿Quieres más pistas? Mirate el ChangeLog del ebuild de Squirrelmail [gentoo.org]. Vete al 12 de Noviembre de 2002. Luego sube al 28 de Junio de 2003. Luego "vuelve" a mirar el bugreport asociado [gentoo.org], donde a su vez hacía referencia a otro bugreport anterior [gentoo.org] igualito a ese, donde este comentario [gentoo.org] deja bastante claro como estaba el tema.

Lo siento, pero por lo general existen muchas formas de hacer las cosas. Y desde luego que Gentoo no sigue la "Debian way" ni ésta tiene por qué ser la única válida ni la más correcta.
La "Debian way" no tiene por ser la más correcta, eso es evidente. De hecho, si hay discusiones en debian-devel es por algo: porque para llegar a una "Debian way" se discuten muchas opciones diferentes, y no siempre tiene porque haber una que destaque de manera notable sobre todas las otras. Cuando se consigue consenso, se deja por escrito como regla a seguir para todos los desarrolladores de Debian. Por lo que yo ví en Gentoo, las cosas se hacían según el desarrollador de turno decidía. Este último sistema tiene sus pros (optimización de recursos humanos), y sus contras (menor QA, falta de consistencia entre paquetes, etc...). No sé si ahora que Gentoo ha ganado adeptos y desarrolladores los de QA se han puesto las pilas y están cambiando las cosas. Pudiera ser. Si es así, pues felicidades; un punto a favor.
Eso si, QA prácticamente siempre viene a costa de flexibilidad. En algunos casos a lo mejor puede llegar a evitarse, pero no es la norma. ¿Que aun así mantengan una flexibilidad mayor que Debian? Es posible, puesto que este es uno de sus objetivos principales, mientras que en Debian es algo deseable pero no imprescindible y por detrás de otras consideraciones.

Ajá. Entonces, si nos regimos por esto, tampoco es seria Debian, pues tiene detrás a unos aficionadillos que andan haciendo por amor al arte la distribución. Ni siquiera Red Hat ofrece seriedad suficiente, puesto que mucho de lo que ofrece no depende más que de aficionados, o peor aún, novatos.
La seriedad o falta de ella no es algo que se mida en billetes. No sé si nunca lo fué, o si lo será, pero en el momento actual y en el mercado del software te aseguro que no. Ser "aficionado" no significa ser "poco serio". Pero hacer paquetes al tuntun sin reglas definidas y "si a mi me funciona lo marco estable" no es seriedad, lo haga un aficionado o una multinacional. Aceptar paquetes de este tipo en el árbol oficial de una distribución, tampoco lo es. Congelar de repente una distribución así, y un par de meses después sacar una "versión estable", tampoco lo es. Si a ti te lo parece, te deseo suerte. Por el momento y por lo que dices, la has tenido en abundancia.

Desde luego que no hace falta porque no es de lo que estoy hablando. Hablo de script(1).
Bueno, algo es algo. Pero me remito al comentario acerca de la ejecución de comandos tras la instalación de un paquete, que de no realizarse en ese momento impide la compilación/instalación de paquetes posteriores. Pero es que aun así, tener que mirar el log de "script" después de cada emerge world para ver qué ha petado, y qué cosas debes hacer a mano, tampoco entra dentro de mi concepto de mantenibilidad. Recalco: en el mío.
Pero volviendo a mi argumento en este punto: 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. Eso si se desea algo de mantenibilidad, claro. ¿O crees que al final pusieron la opción de agrupar los mensajes al final del emerge porque si? Rectificar es de sabios, negar la evidencia no lo es.

Eso es incorrecto. Se daba un ejemplo con -O3 (ya de por sí contraproducente, eso sí). *Nunca* se recomendó
En mi opinión, si en el manual de instalación (que no es como el de Debian, sinó que éste es imprescindible para instalar Gentoo) se muestra la opción -O3 en lugar de la -O2, no se "ejemplifica" nada, se está recomendando. Más aún si en ese mismo sitio no hay ningún enlace a ningún otro documento en el que se recomiende no usarla. Al final lo cambiaron a -O2... creo que fue cuando se comprobó que habían programas que estaban dando errores por la "optimización" -O3.

y sin embargo sí había ya entonces documentación al respecto desaconsejando usar flags demasiado agresivas. Como ves, pequeños detalles que cambian por completo el sentido de un argumento.
¿Donde? ¿En el documento de instalación? No. ¿En algún enlace del documento de instalación? No. ¿En alguna parte que fueses a mirar sin saber de antemano que -O3 *es* problemático? No. Si que es pequeño el detalle, de hecho es TAN insignificante que no cambia el sentido del argumento en lo más mínimo.

Pues eso, que tengo mucha suerte en Gentoo y muy mala en Debian.
Pues fijate, yo debo tener mucha mala suerte en Gentoo. Eso si, en Debian unstable si que estoy acostumbrado a cosas como las que comentas. Yo NO nego que Debian tenga errores, o que algunas cosas las pueda hacer mejor. Y no me molesta que algo sea complicado, si esas complicaciones surgen de la necesidad de estabilidad, consistencia, y mantenibilidad. Tampoco creo que "facilidad" y "mantenibilidad" sean sinónimos. La primera puede ser uno de los factores de la segunda, pero ni su único factor ni de hecho el más importante. Claro que tu puedes no opinar lo mismo.

Bueno, no he querido decir que sea apta para todo el mundo... aunque sigue siendo de un mantenimiento sencillísimo, porque el estar basada en fuentes es una ventaja enorme.
Eso de estar basada "forzosamente" en fuentes es una ventaja que está por demostrar. Parecía interesante, pero al final llegué a la conclusión que para la mayoría del sistema eso era absolutamente innecesario cuando no contraproducente. En mi opinión actual, es un importante error de planteamiento. Te recuerdo que para Debian, RedHat, y derivadas existen src.deb y src.rpm, para que cualquiera pueda compilar un paquete en su distribución si así le interesa.
Y los GRP, bueno... digamos que están bién solo para instalar una versión congelada del sistema, puesto que por lo menos antes (no sé si aun sigue así) los GRP solo los generaban cuando iban a sacar una release nueva. O para instalar rapidito y luego liarte a compilar las nuevas versiones mientras trabajas... solo que la experiencia demuestra que eso por ejemplo en KDE no es muy recomendable (Konqueror casi siempre deja de funcionar correctamente hasta que está compilado con las nuevas librerías).

Cuando me refiero a LA distribución lo hago desde el punto de vista tratado, y por supuesto, para mí (ya están los demás para pensar y decidir por sí solitos).
Perfecto entonces. O no te expresaste bién, o yo te interpreté mal, o una mezcla de ambas.

Si no quieres compilar, no es la mejor para nadie. Está claro. Pero desde el punto de vista de mantenimiento y actualizaciones sencillas (sin tener que rezar), repito, tiene la gran ventaja de estar basada en fuentes y un sistema de paquetes realmente muy bueno.
No es que no quiera compilar. Si quiero añadir un parche a courier-maildrop y compilarlo, puedo hacerlo tanto en Gentoo como en Debian como en RedHat, como en cualquier otra que se precie. Es que no quiero compilar cuando no es necesario ni me aporta ningún beneficio razonable. Simplemente eso. No veo ninguna ventaja en que *debas* compilar cualquier programa por más que no tengas ninguna intención de adaptarlo o parchearlo.
Por otro lado, no me he metido con portage en si. Es lo que aporta nuevas e interesantes ideas... aunque algunas de ellas se hayan demostrado problemáticas ¿Te suenan las discusiones para optimizar el tema del rsync del portage, añadiendo complejidad al portage en si?. A mi si, porque las seguí. Fueron interesantes, de verdad. Lo que no me gustó nada fué la calidad media de los ebuilds, o que las ideas de tener una especie de GRP contínuamente actualizado no acabaran de cuajar (por lo menos, por aquél entonces).
Nota: hablo en pasado porque hace un tiempo que he dejado de interesarme por la evolución de Gentoo. Eventualmente imagino que le pegaré una mirada, a ver qué nuevas ideas se les han ocurrido. Nunca está de más, y repito que algunas ideas son bastante interesantes. Pero dudo que vuelva a instalarla en ninguna parte mientras no cambien muchas cosas de la distribución.

No, yo no he descrito "complejidades de uso". He descrito problemas bien gordos que no se corresponden a "complejidades de uso" (que también las hay y muy molestas, como el tema de los servicios y scripts de arranque).

• La instalación de eclipse es una complejidad, no un error. Puede que la decisión de no incluir esos paquetes sea en si misma una especie de error para algunos, pero para otros no lo es. Por cierto, eclipse no está en main sinó en contrib, y la documentación de Debian deja bién claro qué son esos paquetes.
  
• Espero que lo de XMMS o el gforge no sea uno de esos problemas graves. Ya he comentado que ese tipo de problemas me los he encontrado en Gentoo unas cuantas veces, y un paseito por sus foros o su bugzilla debería darte más pistas. No voy a ser yo quién se los vuelva a patear para buscar esto DE NUEVO.
  
• ¿Problemas con LVMv2? Aún no has comentado cuales eran, ni su gravedad, solo que los solucionaste sin más problemas. Pero es que estás hablando del instalador beta, no del de la estable. El de la estable ni siquiera tiene LVMv2 que yo sepa, solo lo que era estable y estaba bién integrado en el instalador en el momento en que se congeló esa versión. Y aun así, también existe un manual "Debian from Scratch" al estilo del de Gentoo para hacértelo todo a mano "sin errores".
  
• Lo del módulo de PHP tampoco te lo puedo contar como error grave. Son dos paquetes diferentes, con dos nombres diferentes, y sus dependencias las correctas. Pero me suena haber leído algo de lo del metapackage, cuando busqué información sobre los MPM de Apache2. ¿A lo mejor no tenías puesto el apache2-mpm-prefork sinó otro MPM, y por eso se fue por el monte? Puede ser, y de ser el caso es verdad que es muy mejorable y puede llegar a considerarse un bug leve. Pero, ¿qué debería hacer APT en ese caso, cambiarte el MPM de Apache2 por la jeta o instalarte Apache1?. Piensa si tu respuesta se aplica en todos los casos. De hecho, imagino que en bugs.debian.org habrá algo al respecto (nada de foros; si es un bug se discute en bugzilla, y si es un problema más amplio en las listas de correo que para eso están, que una distribución no se lleva desde un foro). Eso si, no es ningún error que te dé a posteriori, sinó un "problema" (paquetes extras) del que te avisa ANTES de empezar a instalar paquetes sin más. Miras porqué pasa, retocas la lista de paquetes solicitados, y adelante. ¿Molesto? Un poco. ¿Complejo? A priori y sin conocer apt, bastante. ¿Mejorable? Seguramente. ¿Un error grave? En mi opinión, no.
  
• Lo de los servicios me suena a chiste. En Gentoo ni se te ocurra cargarte el script de /etc/runlevels/default a pelo, debes usar rc-update para que te actualize las "dependencias" entre scripts. Sinó, errores te esperan en el siguiente arranque. Pues mira, en Debian a parte de poder hacerlo a pelo *como se ha hecho toda la puta vida en todos sitios*, también tienes update-rc.d que se usa prácticamente igual que el rc-update de Gentoo. Por cierto, no empieza por "update-" porque si, sinó porque es una convención de Debian y que usan muchos otros scripts, muy útil cuando no recuerdas el nombre exacto.
  
• Lo de x-window-system-core no es un error, ni está así porque sí o por cabronería. Los paquetes de las XWindow en Debian NO tienen porque ser xfree86, y de hecho hace un tiempo incluso discutieron si hacer una mezcla de los de diferentes proyectos.
  
• Los "syntax error" SI son problemas graves, con los que por suerte aun no me he encontrado, pero que si te salieron por algo debía ser. Esto pedía un bugreport a gritos.

¿Me dejo algo?

Un tipo pone una línea totalmente equivocada que se carga algo en un software completamente beta (que te empeñas en decir que formaba ya parte de la rama estable, dame pruebas), y, usando software beta -esto no lo pondrás en duda, ¿verdad?-, es la hecatombe. No, va a ser que no. Es posible y lo esperable.
Un desarrollador con acceso a meter paquetes en Gentoo escribe una línea completamente errónea (que ya se dió instrucciones de no usar y eliminar en donde estuviese) en un paquete marcado ESTABLE (me remito a los links de unos párrafos arriba para las pruebas que solicitas) de un software maduro y estable, y se carga el primer DocumentRoot configurado en el servidor Apache de la máquina de destino. Eso es un problema GRAVE, denota una enorme falta de coordinación, y una QA pobre. En lo de que estaba usando un software beta, te voy a dar la razón: era portage (sin ánimo de ofender, simplemente es uno de los estados de desarrollo de cualquier software). Y otro en alpha: el ebuild en cuestión, por más que estuviese marcado como estable.

Y yo describo problemas reales bastante menos sutiles que escribir una línea equivocada (como olvidarse de incluir dependencias, instalar pese a no cumplirlas, errores varios en los scripts de pre y postinstalación -varios, nada de una línea en un tipo de paquetes _nuevos_-, etc). Describo tan sólo lo que fue un único día en Debian inestable.
Pues precisamente eso: un comportamiento inestable. Perfectamente "posible y esperable". Aunque dudo que ninguno de ellos se te cargase datos tuyos.

Es muy probable que si me pongo encuentre bastantes cosas más que "complejidades de uso" (estoy por comprobar qué pasa si mezclo algunos paquetes de varias ramas, aunque sea sólo por experimento...).
Fijo. En unstable aparte de las "complejidades de uso" esperables, es donde se testean los paquetes en busca de errores. Y por lo tanto, los hay. Si quieres encontrarte más bién pocos, usa testing. Si quieres encontrarte alguno muy ocasional, si es que llegas a encontrarlo, usa estable. Si no quieres encontrar ni uno, deja la informática, porque esto último no lo vas a encontrar en ningún sistema.
Y si mezclas ramas, pues esperate mil problemas de dependencias, a parte de los del software en si. Eso si, si estás en estable y quieres algo de las ramas más inestables, siempre puedes añadir a apt algunos sources de backports no oficiales que suelen funcionar fantásticamente.

Y por cierto, ya que has insistido tanto en el tema de la información que se pierde, en Debian parece que ocurre algo similar cuando se configuran los paquetes y salen algunos warnings que son seguidos de la configuración de los siguiente paquetes. 0:) Pero bueno, ahora que ya conoces script(1) podrás guardarlos a buen recaudo. ;)
Si te refieres a que pierdes alguna configuración, no se sinó que te pregunta qué quieres hacer con ella: ver las diferencias, meter la nueva, dejar la vieja o salir a shell a toquetear a mano. Se echa en falta el sistema de "diff interactivo" de portage. Realmente útil. Es lo único que echo realmente en falta desde que volví a Debian.
Si te refieres a que te pierdes los warnings, comentarte que no es lo mismo 150 lineas de configuración que 5000 de compilación que vendrían a ser al cambio como mínimo. Y dependiendo del nivel de prioridades del debconf (dpkg-reconfigure debconf, o en la instalación beta lo pregunta), incluso te los muestra por pantalla como si fueran una pregunta, si no me equivoco. Pero claro, tantos "dialogs" pueden marear. Ah, ¿que también se puede usar el interfaz readline?

Poco porque para mantenerlo primero hay que instalarlo. Y si para instalarlo hemos pasado por todos estos problemas, lo último en lo que uno quiere pensar es en cómo será el mantenimiento.
Bueno, es lo que tiene una instalación inestable de una rama inestable, que no va todo a pedir de boca (pero tampoco destroza nada) y menos sin experiencia en dicha distribución. De todos modos, la instalación de Gentoo tampoco suele salir nada fina la primera vez que uno la intenta, y aun gracias si la segunda va bién. "Uy si, si ya está instalada!", y al cabo de un par de días ya andan reinstalandola, porque por ejemplo han desinstalado un paquete imprescindible por el morro sin que portage avise de los paquetes que requieren de este para funcionar. Exagerando un poco: prueba un "apt-get remove libc6", tranquilo que cualquiera se echa atrás.

Por último, no voy a entrar a trapo en esa filosofía de "si a mi no me ha pasado, es que no ocurre".
Ya lo has hecho, y de lleno. En tu caso, "si a ti no te ha pasado, es porque sí ocurre pero usas unas flags idóneas o actualizas contínuamente".
Error de sintaxis (nunca mejor dicho). No es lo mismo "si a mi me ha pasado, es que ocurre", que "si a mi no me ha pasado, es que no ocurre". Lógica de Boole básica.
Yo no he negado nada de lo que te ha pasado a ti en la instalación de Debian, solo he negado (subjetivamente) la gravedad que tu le asignas (subjetivamente, también). Tampoco he negado que tu no hayas tenido problemas con Gentoo, solo he afirmado que YO sí los he tenido (y esta vez, con más pruebas), y que por lo tanto los hay. Si tienes "suerte", pues mejor para ti. También he afirmado que aquellos que yo conozco que hayan usado Gentoo, han tenido problemas. El hecho de que la hayan usado a un nivel más básico también hace que hayan tenido problemas más básicos (compilaciones y dependencias).
Pero es que tu estas negando categóricamente la existencia de los errores con los que yo me HE encontrado, que ESTÁN en los bugreports, y cuyas correcciones ESTÁN documentadas en los ChangeLog. Eso si, los de dependencias si quieres los buscas en los foros o en el bugzilla de Gentoo, es lo que yo tuve que hacer cada vez que no los dilucidaba yo mismo. ¿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, o con tus aportaciones de datos. De hecho, dudo que los hayas buscado tu mismo.

Sí, aunque a mí me gustaría que hicieses lo que yo y nos contaras qué tal te va instalando una Gentoo inestable, a ver si al final tienes tantos problemas como los que yo tuve con Debian sid. :)
Ya he comentado algunos párrafos arriba porqué no voy a instalar otra Gentoo hasta que haya pasado un periodo de tiempo razonable. Y mucho menos una inestable. Porque esos problemas YA los tuve. Con suerte terminas una instalación sin muchos problemas. El mantenimiento de después ya es otro tema.
Tengo otras distribuciones en la lista de "volver a probar", como Suse o Mandrake, y Ubuntu como derivada interesante de Debian. Puede que incluso Novell (por el escritorio y algun otro cambio respecto a Suse). Pero Gentoo casi que la dejo para mucho más adelante, cuando lleve unos añitos de desarrollo.

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