Scripts independientes o mega script de actualización

[jasvazquez]

Tras implementar la tarea #12 y comenzar a usar el script de actualización, surgen dudas sobre la idoneidad o no de este planteamiento por lo que creo esta tarea donde poder debatir las ventajas e inconvenientes asociados, evaluar las distintas opciones y poder tomar una decisión sobre cómo proceder

[jasvazquez]

Andrés, en base a este comentario quizás debemos decidir cuál sería la forma más cómoda y acertada de crear las distintas releases del sistema.

No tengo claro haber entendido la duda que te ha surgido pero intuyo que igual el problema es que sería más práctico contar con dos scripts:

1. Uno para uso interno nuestro que nos permita (a partir de la iso original de Minimo) configurar Mínimo como queremos que funcione
2. Otro para personalización del entorno que permita al profesorado indicar cómo quiere que funcionen determinados aspectos (los que hemos denominado opcionales como el autologin o tener o no instalado Gimp)

¿Es así o es otra la idea que has querido transmitir? 🤔

[aosucas499]

Tal cual!!! Yo creo que es la idea perfecta. Dos para no mezclar. El nuevo script con zenity para personalización me encanta y mantener el update-script para nosotros o si alguien con los conocimientos que tenga una versión anterior instalada en 30 pc's y no quiere andar volviendo a instalar en todos, lo use.

[jasvazquez]

La posibilidad de actualizar equipos me preocupa: el script deberá ser lo "suficientemente fino" como para detectar ese caso y no meter la pata 🙈

[aosucas499]

La otra opción es crear un update-manager y un repositorio en launchpaj 😄

[aosucas499]

Fuera de bromas, dejamos el update script solo para nosotros.

[jasvazquez]

Vale, creamos entonces una tarea para dividir el script en dos:

1. Uno para actualizar la ISO de Minino
2. Otro para personalizar la instalación

La idea original del script que tenemos es que el profesorado sólo tenga que instalar la ISO del Minino "original" y que, gracias al script pueda convertirlo en el Minino "vitaminado" que tenemos actualmente.

Para ellos podría ser algo más costoso (en tiempo) pero la dificultad sería nula (todo lo haría el "mega script")

Podríamos centrarnos en el script y no tener que estar generando (con SystemBack) ISOs cada vez que hagamos una "release" 🤔

[aosucas499]

Mi escasa experiencia me dice que al final van a querer una ISO, y esta distro SystemBack la genera rápidamente, la fibra de 600 que me pusieron sube la ISO en unos minutos. AL final systemback es una herramienta muy poderosa para que cualquier coordinador TIC la use y genere la distro a su antojo para su centro.

Algo me dice que la mayoría no quieren usar un script en la terminal o incluso gráficamente por muy fácil o efectivo que parezca. Muchos compañeros son coordinadores TIC's porque les ha tocado. La ISO que generé desde la original la hice hace una año y no anoté lo que hice, pues era para uso personal. Una ISO es lo más fácil en las releases y mantener los scripts para el que le guste el "cacharreo" o tenga el dominio mínimo de la terminal como para no tener que volver a instalar la ISO en sus 20, 30 o 15 PC's.

[jasvazquez]

Bueno, podemos optar por una solución intermedia e ir viendo cómo evoluciona cada una de las opciones. Me explico:

1. Podemos crear ISOs conforme vayamos generando releases de Minino-TDE y mantener el script (como bien dices) para los que no quieran empezar de cero en los equipos que tienen instalados (esto va a suponer desarrollar algún método para saber en qué versión está y qué debemos actualizar para no cargarnos nada 😅 )
2. Si vemos que la gente se acostumbra (o la acostumbramos) a usar el script y que el sistema se actualice automáticamente podemos plantearnos la posibilidad de no tener que generar ISOs

[aosucas499]

Perfect, ISO's con periocidad y mantener el script.

[aosucas499]

Dividido el script en dos, uno para actualizar iso y otro para añadir opciones, apps...

[jasvazquez]

Genial, buen trabajo Andrés 👍🏻