upgrade de distribucion con yum

[Alvaro Herrera]

Horst H. von Brand escribió:
> Alvaro Herrera <alvherre en alvh.no-ip.org> wrote:
> > Cristian Rodriguez escribió:
> > > El 10/01/07, Horst H. von Brand<vonbrand en inf.utfsm.cl> 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)