El 22 de marzo de 2017, 04:54, Ancor Gonzalez Sosa <ancor@suse.de> escribió:
On 03/21/2017 05:52 PM, José Roberto Alas wrote:
El 20 de marzo de 2017, 17:38, Carlos E. R. <robin.listas@telefonica.net> escribió:
On 2017-03-20 23:31, José Roberto Alas wrote:
El 20 de marzo de 2017, 16:13, Carlos E. R. <> escribió:
Eso en cuanto al núcleo (hablo del core, no del kernel), más o menos un 30% de los paquetes. El resto se toma en buena parte de Tumbleweed, o de lo que fué TW hace meses. Es un proceso complicado, unas cosas son avanzadas, y otras convencionales.
Eso esperaría que así fuera, que los paquetes que están bien probados en TW pasen a Leap. Como lo mencionas es un proceso complicado. Porque hacerlo fácil si se puede hacer difícil.
Bueno, yo no estoy de acuerdo precisamente con Leap, pero es lo que hay.
Están muchas veces discutiendo sobre que versión de qué cosa va a parar a la Leap; a veces el problema es que alguna libreríaa de base es antigua, porque viene de SLE, y no se puede tocar. Pero el nuevo paquete que quieren traer de otra cosa pide una librería más nueva, y hay follón.
Leap se vuelve dependiente de SLE por decirlo así.
Para mi que debería separarse de SLE el desarrollo de Leap, se debería amarrar a Tumbleweed, con paquetes bien probados y actualizados. por otra parte la promoción y uso de una versión LTS debería de ser una gran alternativa, para darle mas uso a openSUSE en un soporte mas largo.
El soporte de larga duración es precisamente el motivo para alinear Leap y SLE (o hacerla dependiente, usando tus palabras). SUSE mantiene SLE por períodos muy largos, con el único requisito de que te actualices entre versiones "menores". Por ejemplo, SLE11-SP4 se publicó en julio de 2015 y todavía recibe actualizaciones y arreglos.
Sin el apoyo de SUSE no resulta realista ofrecer soporte a largo plazo para openSUSE. Ofrecer un mantenimiento de una cierta calidad durante años para una determinada versión de systemd o el núcleo (por poner un par de ejemplos) no es trivial si nadie te paga por ello (por no hablar de lo que pasaría si el mantenedor abandona el proyecto). SUSE lo hace para SLE y openSUSE puede reutilizar ese trabajo haciendo que Leap se base en SLE.
Es de esperar que SP3 (que se usará como base para 42.3) sea la última versión menor de SLE12. Lo que debería significar que 42.3 recibirá soporte durante muuucho tiempo. Es cierto que para beneficiarse de ello, los usuarios de 42.X deben estar en la última versión menor. Algo que (en teoría, como bien puntualiza Carlos E.R.) no debería representar un problema. No es un salto comparable al que existió, por ejemplo, de 13.1 a 13.2.
Así que podríamos decir que 42.X como un todo es LTS, pero sus correspondientes versiones menores no son necesariamente LTS.
No sé si lo expliqué o la lié más. :-)
Claro que si. Muchas gracias por la explicación. La verdad se torna un poco confuso de como se amara Leap a SLE, pero como lo mencionas queda claro para mi. Lo que mencionas que la 42.X se comporta como una LTS por el soporte que recibe de las versiones de SLE es muy importante, ya que si no lo explicas no se comprende. Porque alguien podría tomar una alternativa de montar un servidor con Ubuntu LTS (Por el soporte Largo) en lugar de Leap por no contar con soporte largo. -- Saludos, cheperobert -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org