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 d