Horst H. von Brand escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > Cristian Rodriguez escribió:
> > > El 10/01/07, Horst H. von Brand<[EMAIL PROTECTED]> escribió:
> > > >... porque /esto/ es un soberano lio. Un upgrade de sistema (intenta)
> > > >preservar/migrar las configuraciones existentes, actualizar los paquetes
> > > >que tienes, mantener los contenidos de las particiones, ...
>
> > Irrelevante
>
> Como que irrelevante? Si fuera irrelevante lo que tiene, instalaria cada
> vez y ya.
No, lo que es irrelevante es que la mantencion de la configuracion sea
un lio. Que me importa a mi como usuario si es un lio o no? Si es un
lio, entonces los desarrolladores del sistema tendran que resolver el
lio; yo solo soy el usuario y quiero que el problema este resuelto.
> > > Va a perder mas tiempo en el caso que el upgrade tenga una rana u
> > > ocurra algun problema de dependencias.
>
> > Ridiculo y desinformado. Aca llevo años haciendo "aptitude
> > dist-upgrade" y no he tenido problemas usando la distribucion "Debian
> > testing".
>
> O sea, has ido actualizando /una/ version (linea de desarrollo) de la
> distribucion... esto es mas comparable con "yum update" regular en la rama
> de desarrollo de Fedora que con "upgrade de distribucion cada vez que sale
> una nueva".
En realidad lo que he hecho en varias oportunidades es ir desde una
distribucion estable a la siguiente distribucion pronta-a-ser-estable,
que es una transformacion exactamente equivalente a ir desde una estable
a otra estable (puesto que en todo momento, una distribucion
pronta-a-ser-estable debe ser equivalente a la distribucion estable que
pretende llegar a ser, en terminos de transformacion). Un ejemplo de
esto es ir desde Sarge hasta Etch, antes que Etch sea liberado como
distribucion estable.
Observa que en Debian existe la operacion "aptitude upgrade", que hace
lo del "yum update", y existe la operacion "aptitude dist-upgrade", que
es una transformacion de nivel superior, en la cual se permiten varias
sub-operaciones que en su conjunto permiten ir de una version de la
distribucion a la siguiente (por ej. de Sarge a Etch). Si uno hace
solamente "aptitude upgrade", los paquetes van a ir cambiando de
version, como uno espera, pero algunas cosas mantienen la forma que
tiene la distribucion de partida. Pero el "aptitude dist-upgrade" no
tiene esa restriccion y puede hacer cambios mayores que permiten el
upgrade de version.
Volviendo al parrafo de arriba, sobre que una distribucion
pronta-a-ser-estable debe ser equivalente a la estable a la que precede:
cada actualizacion que se ejecuta en medio puede ser un upgrade o un
dist-upgrade, y por lo tanto en cada paso pueden o no ser ejecutados los
procesos de transformacion que te llevan a la siguiente version. Por lo
tanto cada dist-upgrade es en realidad el paso desde una distribucion, a
una distribucion de version superior.
El tema es que los paquetes en Debian deben especificar la
transformabilidad en la version de la distribucion siguiente, es decir,
los desarrolladores deben preocuparse de que los dist-upgrade funcionen.
Antes de ser aceptado en la distribucion "testing", los paquetes pasan
por "unstable" y es ahi donde estos detalles de si el dist-upgrade
funciona o no deben ser resueltos.
Si los lios de dist-upgrade no han sido resueltos, entonces hay un
"release critical bug" y por lo tanto la distribucion Etch no puede ser
liberada. Esto quiere decir que Etch solo puede ser liberada cuando es
totalmente posible ir desde Sarge hacia Etch sin ningun inconveniente.
Este debe ser uno de los motivos mas importantes por los cuales una
distribucion Debian toma bastante tiempo en ser liberada; porque la
actualizabilidad desde una version anterior es _fundamental_.
> > Mas correcto es decir que Yum no soporta ese modo de operacion, sin
> > necesidad de tirar mierda al vecino.
>
> No lo soporta, porque Fedora cambia /rapido/, y un salto de 6 a 9 meses de
> nuevas versiones es un riesgo importante, con muy alta probabilidad que no
> se pueda tener coexitiendo piezas viejas y nuevas; ademas que Fedora apunta
> a manejo simple, con lo que la opcion de "si algo queda tuerto, el usuario
> lo arregla sin darse cuenta casi" /no/ corre. Simplemente consideran mas
> importantes otras cosas, y tienen otros objetivos. Cada cual a lo suyo.
Como corolario deberia ser bastante obvio que mantener servidores en
Fedora Core es altamente irresponsable.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree. (Don Knuth)
From [EMAIL PROTECTED] Fri Jan 12 17:25:42 2007
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Ovidio_Mart=EDnez_Barco?=)
Date: Fri Jan 12 17:24:55 2007
Subject: Paquete xntp para Red Hat
Message-ID: <[EMAIL PROTECTED]>
Buenas las tengan todos ...
Donde puedo conseguir un paquete .rpm o el suurce del programa xntp
para instalarlo en Red Hat 9. Agradeceria su ayuda por que necesito que
algunos equipos
clientes sincronicen su hora al momento de su encendido con la hora de mi
servidor que tiene Red Hat instalado.
Gracias ;-)
From [EMAIL PROTECTED] Fri Jan 12 17:39:14 2007
From: [EMAIL PROTECTED] (Rodrigo Fuentealba)
Date: Fri Jan 12 17:38:27 2007
Subject: upgrade de distribucion con yum
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
El 12/01/07, Alvaro Herrera<[EMAIL PROTECTED]> escribió:
> Horst H. von Brand escribió:
> > O sea, has ido actualizando /una/ version (linea de desarrollo) de la
> > distribucion... esto es mas comparable con "yum update" regular en la rama
> > de desarrollo de Fedora que con "upgrade de distribucion cada vez que sale
> > una nueva".
yum update != apt-get update && apt-get dist-upgrade
> Si los lios de dist-upgrade no han sido resueltos, entonces hay un
> "release critical bug" y por lo tanto la distribucion Etch no puede ser
> liberada. Esto quiere decir que Etch solo puede ser liberada cuando es
> totalmente posible ir desde Sarge hacia Etch sin ningun inconveniente.
>
> Este debe ser uno de los motivos mas importantes por los cuales una
> distribucion Debian toma bastante tiempo en ser liberada; porque la
> actualizabilidad desde una version anterior es _fundamental_.
Me dio risa, se lee algo asi como "hey! tengo una distribucion de
10000 packages y me demoro dos meses en compilarlos y dejarlos
estables... el unico problemita es que me demoro un año en hacer el
instalador".
Está bien que las cosas sean pensadas para que para el usuario sea
transparente, pero no es mejor simplificar las cosas?
En Slackware yo puedo seguir actualizando y actualizando, ya que la
próxima versión estable tendrá siempre la misma estructura de paquetes
que la anterior. Hay packages nuevos, y si se requieren, hay dos
formas de saberlo: una es leyendo el CHANGELOG, y la otra es que si
esos packages son requeridos (el caso de attr para Apache, que ahora
se distribuye aparte), Swaret automágicamente instala ese package por
mí.
Sé que el manejo de packages de Slackware es ineficiente si lo
comparamos con yum, y aun más con apt-get/aptitude, y que no se
detecta si una biblioteca deja de ser requerida por otros programas
que he desinstalado, y que además podría haber inconsistencias (p.ej.
Ruby 1.84.20 pasó a Ruby 1.85 y volvió a 1.84.20 porque rompía muchos
programas... aunque 1.85 no estuvo más de cinco horas en el server),
pero al menos a mí me acomoda saber que tener -current instalado me va
a entregar todos los packages fresquitos y no tengo que esperar de 6
a 9 meses.
Es una estructura que se ha probado por 13 años (logicamente con
enormes cambios, pero manteniendo la idea original de apegarse a la
estructura BSD en vez de Sys-V).
> Como corolario deberia ser bastante obvio que mantener servidores en
> Fedora Core es altamente irresponsable.
;-)
--
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org
