El día 30 de septiembre de 2008 15:29, Marcos Guglielmetti <[email protected]> escribió:
El Martes, 30 de Septiembre de 2008 17:55, minombresbond escribió: | El día 29 de septiembre de 2008 13:32, Pablo Lozano | | <[email protected]> escribió: | > Yo estoy en SID y anda bárbaro, sólo hay que tener ojo con la | > costumbre que tienen algunos de darle "apt-get upgrade" o | > "dist-upgrade" (safe-upgrade tengo yo) cada vez que se arranca | > la máquina, por lo general cuando aparece algo que da conflicto | > se resuelve en horas o en dos o tres días con otro apt-get | > upgrade. Y le exijo mucho a musix (además lo he achurado por | > todos lados): Tengo algunos fallos o demoras al arranque, pero | > creo que son culpa mía, y son dos: | > | > empieza a arrancar, carga todo hasta que llega a manager: nose | > que cosa, y dice ivman, ahí se queda hasta que le doy control+c | > y sigue cargando perfectamente, | > | > el otro es que cada vez que arranco tengo que darle un | > dpkg-reconfigure hal dbus porque me da un "failed to initilize | > hal" todas las veces... | | a mi me llega a pasar eso y puede q me de un sincope o algo | parecido | | apt-get upgrade no es por ejemplo para pasar de estable a testing?
Podés usarlo para eso si querés, pero no necesariamente es para eso.
Es para actualizar los paquetes que estén disponibles para actualizar en la versión que sea que estés (o mejor dicho, a la versión a la que apunta tu sources.list, si apunta a testing, a testing, si a unstable, a unstable, si a stable, a stable)... sin eliminar nada para resolver dependencias.
ah entiendo, actualizaria los 150 paquetes q siempre tengo desactualizados automaticamente!
Incluso se puede utilizar para desactualizar, del mismo modo pero al revés (si estás usando testing y deshabilitás ese repo en sources.list, y habilitás stable, haría un downgrade)
Si estás usando la rama Stable, entonces actualizará lo que encuentre actualizado allí (ejemplo: reparaciones de errores de seguridad), sin borrar nada.
Si estás usando la rama Testing, entonces actualizará lo que encuentre actualizado allí (ejemplo: reparaciones de errores de seguridad), sin borrar nada.
Si estás usando la rama Unstable, entonces actualizará lo que encuentre actualizado allí (ejemplo: reparaciones de errores de seguridad, nuevas versiones de los paquetes, que son más frecuentes que en testing, o sea, en testing cuando se está por congelar o se congelan los repositorios, las actualizaciones son casi como en stable), sin borrar nada.
si, me di cuenta de cual es el ritmo de actualizaciones jaja
| por q alguien le daria en cada arranque? disculpen la ignorancia | | yo tengo testing, me limito a actualizar los paquetes desde | synaptic (q siempre son mas de 150), y en las aplicaciones que uso | todavia no me di cuenta q tiene de menos estable |
Testing o Unstable son menos estables _como repositorios_.
Es decir, los paquetes se mueven mucho en unstable, se renuevan mucho. En testing, según la época del ciclo, ahora deberían ser pocos los que se renuevan.
En estable, poquísimos.
Ahora, a la hora de hablar de estabilidad _de aplicaciones_ en sí, se supone -y en general es así- que las que están en debian stable son más estables que las del repositorio unstable, pero a veces sucede que las nuevas versiones que hay en unstable son más estables que las de los repositorios estables
el problema con unstable es la inestabilidad de los repositorios, y que en ellos pueden entrar aplicaciones con fallos críticos.
en testing no pueden ingresar con fallos críticos
si, yo soy muy amigo de los estables, desde antes de ser un gnusuario incluso, pero el tema que el software para diseño implementa funcionalidades 'criticas' en las nuevas versiones, incluso las que estan en el svn, y bajarse la ultima version es importante, supongo q en unos años eso cambiara saludos!
en estable menos.
-- Marcos Guglielmetti - www.foros.musix.es | Soporte comunitario
_______________________________________________ Musix GNU+Linux - www.musix.org.ar Musix-usuarios mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/musix-usuarios