On Tuesday, July 21, 2020 1:27:28 PM CEST Rafa Griman wrote:
Hola :)
On Tue, Jul 21, 2020 at 11:21 AM Ancor Gonzalez Sosa
wrote: [...] No quieren hacerlo, precisamente para que uses btrfs.
¿Tienes algún enlace donde se explique eso? Es decir, que los desarrolladores de zypper se niegan a desarrollar esa funcionalidad para forzar el uso de Btrfs.
Alguna vez preguntamos que porque no hacían tal y cual y dijeron que no hacia falta, porque btrfs tenia snapshots. Pero no te puedo decir exactamente donde y cuando, mi memoria no llega a tanto.
Ok. No es por meterme donde no me llaman, pero lo anterior no me suena a "No quieren hacerlo, precisamente para que uses btrfs", si no más bien a "Dicen que no merece la pena el esfuerzo de hacerlo, ya que quien quiera snapshots puede usar btrfs"(*).
Creo que hay importantes matices que diferencian a ambas formas de expresarlo. ;-)
Sí, pero el hecho de no desarrollarlo ... te obliga a usar btrfs (o LVM) si quieres rollback, no hay otra alternativa. YUM incluye rollbacks independientemente del sistema de ficheros. En el caso de Zypper, si quieres rollbacks, TIENES que usar btrfs o LVM ... No hay elección.
Perdon por entrar en la discusion. Si no entiendo mal, "yum rollback" dependeria de almacenar los rpms antiguos en algun lado, no? La idea de snapper + btrfs es que no se necesita tener una base de datos de rpms antiguos (local o en repositorio), y ademas queda generalizado para binarios y para ficheros de configuracion. Puedes recuperar el estado completo de un sistema, no solo la version de un paquete. Es este ultimo punto, tener una ya solucion generalizada external al gestor de paquetes, es lo que dificulta el argumento de implementar otra solucion que tecnicamente seria inferior.
En el caso de YUM (AFAIK), es una entrada en la BBDD de paquetes (de YUM, no en la de RPM) ... no han hecho nada "extraordinario/fuera de este mundo". AFAIK.
Implementar una bd de versiones paquetes en zypper podria tener sentido. Tener algo como "zypper history" seria util.
Ojo ! Esto es sólo una idea. Zypper es "propiedad" de SUSE y tiene todo el derecho del Mundo a no implementar el rollback en/dentro de zypper.
https://github.com/openSUSE/zypper (GPLv2) Se pueden enviar PR.
Sigo pensando que no debe ser una tarea hercúlea desarrollarlo y sería una opción bastante útil si, por ejemplo, estás con un sistema IoT y no tienes los 50 GB necesarios/recomendados para montar btrfs o LVM ... pero necesitas rollback porque el equipo/servidor está en un sitio remoto con difícil acceso físico: típico en entornos de laboratorio, I+D, ... en los que hay equipos en medio de la "nada".
Uhm MicroOS funciona con btrfs en sistemas ARM. Se hace rollback automatico en cuanto se encuentra algun problema.
Vuelvo a lo de antes, FLOSS: la F viene de Free as in Free Speech ... IOW: libertad. Y una de esas libertades es la libertad a elegir (en este caso: elegir el sistema de ficheros que uno conoce/usa/le gusta/le viene mejor/...).
Uau, Rafa, estas muy confundido. Free/libre no se refiere a la libertad de elegir nada. Es la libertad que se le da al usuario de inspeccionar, modificar y distribuir el codigo fuente alterado. En ese sentido, zypper esta en github bajo GPLv2. Es C++, y ya hay gente ejercitando la libertad que ofrece FLOSS: https://github.com/openSUSE/zypper/pulls -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer