Actualizar el sistema puede parecer un asunto intrascendente, pero según la distribución que se utilice existen unas reglas u otras y conviene conocerlas para evitar percances. En el caso de openSUSE no difieren apenas de lo normal, pero se complican en relación a los repositorios utilizados. Esto afecta a las dos ediciones principales, Leap y Tumbleweed, si bien la segunda es la más delicada y la que más debates ha generado a este respecto.
De las diferencias entre openSUSE Leap y Tumbleweed hemos hablado en numerosas ocasiones, por lo que a grandes rasgos podemos resumir la definición de ambas en «la estable» y «la rolling release» respectivamente. Leap toma la base de SUSE Linux Enterprise y le pone encima mucho del software -ciertos componentes del sistema, pero sobre todo entornos de escritorio y aplicaciones- llegado desde Tumbleweed, mientras que esta se alimenta directamente de los repositorios de entrada y refina su oferta mediante pruebas de calidad automáticas.
La pareja compuesta por Leap y Tumbleweed es redonda, porque se complementan: una es para quienes buscan estabilidad y un soporte correcto, la otra para quienes desean estar a la última. Pero, ¿y a la hora de actualizar? ¿Es lo mismo? Lo cierto es que sí, y por eso las discusiones a las que he aludido me resultan un tanto extrañas. Desafortundamente, la documentación oficial no aclara nada salvo lo que acabo de mencionar: a más repositorios, más cuidado se necesita. Luego hay opiniones para todos los gustos.
Así que yo os voy a dar mi opinión como usuario veterano de openSUSE, además de varias fuentes para que podáis formar la vuestra si es que os interesa adentraros con éxito en los dominios del camaleón de GNU/Linux.
Para quien no quiera profundizar, la versión corta:
Actualizar openSUSE Leap y Tumbleweed es tan sencillo como utilizar el gestor de actualizaciones automático o en su defecto el comando zypper up, pero nunca zypper dup (up por update, dup por dist-upgrade).
Si os sorprende tanto rollo para terminar recomendando lo básico, razón no os falta. Veamos ahora la versión extendida con especial atención en Tumbleweed.
PackageKit a la hoguera
Lo mismo que os recomendamos el otro día para Fedora se aplica para Tumbleweed: PackageKit es un estorbo, cuando no un problema. Solo sirve para la gestión automática de actualizaciones y por si se usa Discover o GNOME Software, totalmente prescindibles existiendo YaST. Por lo tanto, desinstalar PackageKit es lo primero que hago cuando instalo openSUSE, sea Tumbleweed o Leap, y no solo eso: lo marco como ‘tabú’ para que el sistema no vuelva a reinstalarlo (no digo que hagáis lo mismo, ojo). A cambio toca actualizar a mano vía YaST o por consola, pero merece la pena.
Una muestra más específica de por qué usar PackageKit en Tumbleweed no es una buena lo daban hace unas semanas en Reddit con la siguiente imagen.
Hay cosas para las que PackageKit no está preparado
No obstante, cabe señalar que en el caso de Tumbleweed hablamos de una rolling release pura, de manera que las actualizaciones que recibe son constantes y cuantiosas y es conveniente no dejar que se vayan acumulando. En resumen: actualización manual, pero frecuente; mínimo una vez a la semana.
Zypper manda
Acabo de decir que, una vez nos hemos librado de PackageKit, openSUSE se puede actualizar vía YaST (equivalente a un zypper up) o por consola. Pero considero recomendable priorizar esta última por las ventajas que tiene e incluyo aquí a Leap, aunque es en Tumbleweed donde es verdaderamente importante hacerlo así. De hecho, en las discusiones sobre cuál es el método indicado para actualizar Tumbleweed solo se contempla la consola.
En cuanto a comandos de actualización, con uno debería bastar, pero son dos los los que vamos a tener en consideración según la situación:
zypper up zypper dup --no-allow-vendor-change
¿Por qué dos comandos? El primero equivaldría a la actualización normal y corriente, la misma que se realizaría a través de YaST o PackageKit; el segundo equivaldría a una actualización más profunda que incluye todos los repositorios activos, con el límite que fijan los parámetros añadidos. Así, usar uno u otro dependerá de la configuración de repositorios que tenga el usuario.
Por ejemplo, cualquier usuario de Tumbleweed que se conforme con los tres repositorios básicos (Update, OSS y NON-OSS) que ofrece la distribución o quizás alguno más de bajo impacto (Packman para el soporte multimedia o aplicaciones independientes), tendrá suficiente con un zypper up, mientras que un zypper dup hará prácticamente lo mismo, por lo que es prescindible.
Lo delicado de actualizar Tumbleweed aparece cuando se añaden diferentes repositorios que contienen paquetes duplicados e incompatibles entre sí, por ejemplo, relacionados con el entorno de escritorio, el servidor gráfico, componentes del kernel, etc. En este caso zypper up sigue siendo una opción válida y, por el contrario, zypper dup es una temeridad , pues usado sin más parámetros actualizará todos los paquetes a su versión más reciente sin importar el repositorio en el que estén. Sin embargo, lo más recomendable es hacer un zypper dup –no-allow-vendor-change. ¿Por qué? Veamos un ejemplo concreto.
En cualquier caso, la instalación por consola de un nuevo repositorio se hará así:
zypper ar -f URL nombre
Por partes, con ese comando estamos añadiendo un repositorio, refrescando la lista de repositorios, añadiendo la URL del repositorio y dándole un nombre para identificarlo.
El siguiente paso sería instalar el paquete en cuestión y se pueden dar dos circunstancias: que se trate de un paquete independiente que todavía no tengamos instalado, o de una versión más reciente de un paquete que ya está en los repositorios. En el ejemplo que estamos viendo se trata de lo segundo, pues lo primero no comprende mayor complicación. El método consistiría en actualizar todos los paquetes desde el repositorio específico que acabamos de añadir:
zypper dup --from nombre
De este modo estaríamos actualizando paquetes ya presentes en el sistema, y no tiene por qué tratarse de versiones más nuevas siempre. En ocasiones el repositorio puede incluir versiones más antiguas, pero especialmente parcheadas por el motivo que sea. Pues bien, si después de instalarlo ejecutásemos un zypper dup, nos cargaríamos todos los cambios. ¿Cómo evitarlo? De dos formas:
- Una vez realizada la instalación, asignándole una prioridad mayor a ese repositorio, en cuyo caso un zypper up sería suficiente para actualizar el sistema.
- Una vez realizada la instalación, con el comando zypper dup –no-allow-vendor-change y nada más.
Utilizar este último comando es también interesante porque a diferencia de una simple actualización, implica una actualización completa de la distribución, de manera que limpia paquetes huérfanos que hayan podido quedar por ahí. No obstante, esto es poco más que un detalle que no supone ningún problema: no suelen ocupar gran espacio en disco y no molestan.
Otro aspecto a considerar es, parece ser, que muy pocos usuarios se preocupan por configurar la prioridad de los repositorios, y es más «fácil» lanzar un único comando, que en este caso sería el segundo mencionado: zypper dup –no-allow-vendor-change. Así, el resultado es una actualización de las últimas versiones de los paquetes, pero sin cambios inesperados de repositorio, de manera que un zypper up vuelve a ser una buena elección.
Asignar una prioridad a los repositorios es muy sencillo
Pero aún se puede complicar más la cosa. Supongamos que instalamos un nuevo repositorio para reemplazar solo unos paquetes determinados, pero no todos. Esto es algo peligroso para quien no domine el sistema y sepa solucionar los desaguisados que puedan surgir, pero sirve como ejemplo extremo. En este caso,tras la instalación del repositorio habría que actualizar manualmente los paquetes y lidiar con las dependencias, pero una vez hecho se presenta un nuevo contratiempo: la prioridad de los repositorios deja de ser fiable, porque asignarla implica que en la siguiente actualización va a priorizar los paquetes de dicho repositorio. Por lo tanto, el comando zypper dup –no-allow-vendor-change vuelve a ser el recomendado.
¿Mucho lío? Simplifiquemos:
- Si no añades repositorios adicionales a Tumbleweed, usa zypper up.
- Si añades repositorios adicionales a Tumbleweed, usa siempre zypper dup –no-allow-vendor-change.
Y en cuanto a Leap, el riesgo de romper el sistema es mucho menor debido a que la base se mantiene sin tantos cambios, por lo que es muy difícil que los repositorios que se agreguen creen conflicto por el número de versión de los paquetes. Por lo general, siempre estarán más actualizados que los de los repositorios del sistema.
Por último, una aclaración acerca de Tumbleweed: una vez instalada se comporta de manera estable y responsiva, ergo, es fiable en su uso y la experiencia es buena. Sin embargo, no está hecha para ofrecer estabilidad o facilitar ciertas tareas (por ejemplo, los controladores de vídeo privativos hay que gestionarlos manualmente), por lo que quienes buscan estabilidad harían bien en decantarse por openSUSE Leap, así como quienes buscan actualización continua con todas las facilidades posibles tienen soluciones más amigables a su alcance, como Antergos o Manjaro, aunque esto suponga saltar al ámbito de Arch Linux.
A todos esto, os interesará conocer otras opiniones, así que aquí dejo esta fuente y esta otra, donde se debaten los pormenores de actualizar Tumbleweed.
Actualización: Ya no es preciso usar el comando mencionado, sino que con un zypper dup es suficiente para actualizar sin problemas. Más información.
