Una idea para Mandriva: paquetes de instalaciòn autosuficientes

Eso se puede hacer desde hace muchísimos años, siempre se han podido compilar programas de forma estática, pero no se hace por el peso de los binarios.

En sistemas Windows se compilan asi las aplicaciones, en sistemas *nix no se hace, debido a eso es que los sistemas *nix son tan minimalistas en comparaciones con las instalaciones monstruosas de sistemas Windows.

Entiendo que serian de gran ayuda para usuarios offline pero en lugar de ello creo que la solución no es el empaquetado sino una aplicación que adecue la instalación a entornos sin red.

Es mas sencillo y viable proyectos como urpmi offline o hacer que urpmi pueda agregar repositorios sin necesidad de Internet.

El problema no es el espacio en el disco, sino que se termina gastando mas ancho de banda y con los mal llamados "auto suficientes" lo que se logra es perjudicar a los que si tienen conexion, porque se les obliga a bajar binarios mas pesados.

Con los paquetes "auto suficientes" se busca ayudar a los que no tienen conexión pero con ellos se les obliga a gastar mas en conexión por el peso de los mismos, como dije si esto es posible desde hace mucho y no se usa es por algo.

EMHO el problema no esta en el empaquetado sino en mejorar urpmi.

--
Temporada de caza de Koalas | ¿Quien es Jesucristo?

El espacio en disco ya no es problema...

Y además multi-distribución.

La idea no era tanto instalar los programas "a lo mac" sino más bien probar novedades, en su día amarok sacó paquetes así.

Sin embargo la idea al final no cuajó, el por que no lo se.

Cualquiera que trabaje con un mac ve como el directorio /Aplicaciones va creciendo de forma alarmante, en un viejo powerbook tuve que hacerle una gran limpieza de aplicaciones que en otro *nix no hubieran supuesto ningún problema.

Aunque por otra parte, también es cierto que ahora los discos son gigantescos.

Mejor me gustaría ver en mandriva algo como Presto para fedora, algo para manejar los delta rpms :S

---

KDirWatch::setDirty

Cómo hacer un bebé?

Aunque ya existen cosas así, como autopackage y similares, tienen el problema de la redundancia, lo que dificulta el mantenimiento del sistema, aunque colateralmente "soluciona" otro problema.

lo que si encontraría bien es que existiesen unos metapaquetes de paquetes rpm, algo así como un tar (por poner un ejemplo) que contenga un mini repositorio urpmi que contenga el rpm del programa en cuestión y aquellos rpm de los que depende que no vengan incluidos en la Mandriva One.

Por ejemplo, quieres instalar el Octave, el cual depende a su vez de libcolamd2.7.1, de libhdf5_5 y de gnuplot (no se si este viene en la One, pero bueno, para el caso, me vale), pues el metapaquete de Octave incluiría los rpm ocvtave, libcolamd2.7.1, libhdf5_5 y gnuplot, y cuando instales el metapaquete te instalará sólo aquellos paquetes (reflejándolo en la base de datos de rpm) que no tengas instalados, o actualizando si alguno es más moderno que los instalados. De esta manera, cuando actualices mediante un urpmi --auto-update, te actualizaría también estos paquetes, y sí no tienes Internet a mano también te aseguras poder instalar programas complejos totalmente offline.

Pero no estoy de acuerdo en que Mandriva tenga que tener un sistema paralelo a los rpm. Eso además teniendo en cuenta de que ya existe, y que tu como usuario/administrador puedes emplearlo ignorando las herramientas de instalación y actualización de software.

En Windows y Mac tienen lo que tienen porque no disponen de ninguna herramienta automática de instalación y actualización del sistema, dónde te actualice de forma automática todo el software instalado, y por eso tienen que ir con chapuzas.

--------------------

Speedball, la banda de heavy metal más barriobajera de Tarragona, que ya no tiene web ni, conexión a Internet, ni teléfono, por cortesía de Telefónica.

No es por ser prácticamente el padre de la criatura pero con la pagina de DependenciasDrake o con las interfaces gráficas de la versión offline es muy fácil obtener todo lo necesario para instalar un paquete (o lista de paquetes)

Miembro de NoticiasDrake, MdkTrans y del grupo de Empaquetadores

Me parece una exelente idea pero hasta que no la pongas en marcha, nadie la va a tomar en cuenta. No le prestes atencion a comentarios negativos, porque lo unico que hacen es retrazar los avances.

En mi opinión tal como lo plantea el compañero Tavillo, Aunque sea como un mecanismo complementario, la adopción de este tipo de métodos supone una evidente Involución.

Reflexionando un poco podemos plantearnos la siguiente interrogante:

¿Para que pretender que se adopten otro tipo de mecanismos menos sofisticados y evolucionados para la obtención de paquetes?

Les invito a leer un pequeño análisis que hice al respecto:

Gestión de Paquetes y Programas "Autosuficientes"

Saludos!

El sistema rpm no necesita ser modificado prácticamente nada y las librerías estáticas son innecesarias.

Supongamos un paquete llamado aplicaciónprincipal.arq.rpm cuyas dependencias son librería1.arq.rpm y librería2.arq.rpm. Se cogen los tres paquetes rpms y se ensamblan en un tarball pero en lugar de llamarlo .tar lo llamamos .ret (rpms en tar) o cualquier otro nombre, es decir aplicaciónprincipal.arq.ret

Se modifica muy ligeramente la aplicación rpm para que cuando el usuario haga #rpm -ivh aplicaciónprincipal.ret (o doble click con el ratón sobre el icono) se instalen todos los rpms contenidos excepto aquellos rpms que ya estén instalados en el sistema.

La persona que construya un .ret normalmente añadirá el rpm correspondiente a una aplicación con GUI y todos aquellos rpms que estime que son necesarios para su instalación y que no vienen en el DVD de instalación de Mandriva.

Si estos .ret son software libre no debe haber problemas en ponerlos en redes P2P, en CD's de revistas de informática o donde sea. Si contienen software no libre hay que pedir permiso para ponerlos en según que sitios.

Por lo demás los .ret no se intentan desinstalar sino que se desinstalan los rpms componentes como normalmente se hace.

Quizás la idea que he propuesto sea una tontería pero es lo que se me ocurre para satisfacer a un determinado tipo de usuarios.

Creo que seria mas fácil modificar urpmi que crear un sistema paralelo para manipular paquetes estáticos.

¿Como seria esto?.
Integrar una opción en urpmi, que en lugar de descargar aquellos paquetes disponibles en repositorios remotos, devuelva una lista con las rutas absolutas de los paquetes.

¿Pero de donde sacaría la información de los repositorios remotos si no tiene acceso a internet?.
Pues se podría descargar los hdlist de los repositorios que desee utilizar y los agregue donde corresponde. De esta forma urpmi seguiría funcionando como de costumbre, solo que al indicarle con opción de por medio, devuelva una lista en lugar de intentar realizar la descarga.

¿Y como termina la cosa?
Pues se va a algún lugar con internet, se usa un gestor cualquiera de descarga dependiendo del OS. Luego se los copia a un pendrive y finaliza con la instalación de estos paquetes.

Resumiendo, el usuario solo debería seguir estos pasos:

1. descarga los hdlist de los repositorios (se podria poner a disposicion una interface dentro de bdk en php para facilitar esta tarea)


2. ejecutar urpmi --offile [lista paquetes] [nombrearchivo]


3. Utilizar el archivo en cuestion para realizar la descarga. (Se descarga SOLO lo necesario)


4. Instalar con dependencia resueltas y todo.

¿Porque no eh hecho yo esta modificación?
Aunque lo intente, mi conocimiento de Perl (ese es el lenguaje de prácticamente todos los asistentes de MDV) es muy básico(diría nulo), ademas de lo criptográfico del lenguaje que lo hace mas difícil :S

También se podría agregar la opción en RPMDrake para que devuelva un archivo con la lista de paquetes en lugar de descargarlos.

¿Otra posibilidad?

Que se creen DVD's y CD's de los repositorios, (Recuerdo que en el wiki había una explicación de como crearlos) y que a determinado tiempo de la release, se creen CD's y DVD's con los updates.

Saludos

 
"Cuando hay libertad, todo lo demás sobra."
Participa de la comunidad!!