close Warning: Can't synchronize with repository "(default)" (/var/svn/tolp does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#1368 closed defect (fixed)

TolPackage: Revisar la gestión de los updates de los paquetes

Reported by: Pedro Gea Owned by: Víctor de Buen Remiro
Priority: highest Milestone: TOL Packages
Component: Various Version: head
Severity: critical Keywords:
Cc: Jorge

Description

En la gestión de los paquetes se tratan dos tipos de actualización:

  • Update: actualización de un paquete con una versión concreta porque existe una versión más actual.
  • Upgrade: actualización de un paquete a una versión superior.

La información de la fecha de release del paquete no está en el paquete, de modo que esta información sólo reside en el archivo "VersSyncInfo" (penúltima columna). Esto provoca las siguientes dificultades:

  • Si este archivo se pierde no hay forma de reconstruirlo.
  • Si algunos paquetes se instalan desde un zip no se puede actualizar la información del archivo "VersSyncInfo".

Se sugiere la siguiente opción: Incluir un atributo _.autodoc.releaseDate obligatorio en los paquetes y que ha de rellenarse (para dar homogeneidad en los fechados) con la fecha o instante del repositorio en el momento de la construcción del paquete.

Esta fecha también podría incluise junto al oza del paquete en el zip de modo que facilitara la obtención de la fecha de un paquete instalado sin necesidad de cargarlo.

Change History (10)

comment:1 Changed 13 years ago by Víctor de Buen Remiro

Cc: Jorge added

Hay varios problemas al respecto que voy a ver si soy capaz de explicar.

El principal obstáculo es que para poder comparar la fecha local con la remota no podemos esperar a cargar el oza del paquete local, pues es algo que ralentizaría muchísimo todos los procesos de mantenimiento de paquetes en TolPackage::Client. Por ello hay que basarse en la fecha del archivo local ".oza".

Si queremos que esa información sea además un miembro del NameBlock entonces hay que asegurarse en tiempo de creación del paquete, de que existe el miembro y de crearlo en caso contrario para asegurar compatibilidad hacia atrás; y también de que su valor coincide con la fecha del archivo ".oza", el cual se crea precisamente con un Ois.Store de ese NameBlock, necesariamente después de haberlo modificado, por lo que el reloj ha corrido mientras tanto y ya no es el mismo instante.

Eso implica por tanto que

  • hay que hacer una función para añadir un miembro a un NameBlock que es algo que no me gusta nada porque es muy peligroso pero que ya he resuelto en el ticket #1368
  • hay que modificar la fecha del archivo después de crearlo y habría que crear una función TOL para ello porque creo que no la hay y de hecho ni siquiera sé cómo se hace en C++ de forma independiente de la plataforma. En vez de ello se podría hacer una función de comparación más compleja que sólo tuviera en cuenta diferencias de al menos 1 minuto, por decir algo.

Hay otro problema relacionado con esto y es que la fecha del archivo debe ser independiente de la zona horaria en la que se ha creado el paquete y de la zona horaria en la que se carga, que no tiene porqué ser la misma como es lógico.

En principio yo trato de usar la fecha y hora GMT pero no tengo nada claro qué es lo que pasa con las fechas de los ficheros.

Lo ideal sería tal vez poder hacer carga parcial del ".oza" para obtener tan sólo los miembros informativos y así prescindir de la fecha del archivo sin apenas coste computacional. Puedo intentar rescatar esta característica de OIS que dejó de funcionar hace mucho tiempo debido a la gran cantidad de cambios que se hicieron y a que no se usaba en ninguna parte.

Otra opción posible, aunque bastante engorrosa y no exenta de riesgos, sería incluir en el ".zip" un archivo ".bst" con la información documental del paquete, que en caso de pérdida accidental podría ser regenerada fácilmente.

comment:2 Changed 13 years ago by Víctor de Buen Remiro

Perdón por el desliz, lo de añadir un miembro a un NameBlock se trata en el ticket #1370, no en el 1368 que es este mismo.

comment:3 Changed 13 years ago by Víctor de Buen Remiro

Después de revisar todo más a fondo he llegado a la conclusión de que la única forma de poder atacar este problema, y otros relacionados con la información documental de los paquetes, es incluirla como un archivo aparte dentro del ".zip"

comment:4 Changed 13 years ago by Víctor de Buen Remiro

Quizás lo más sensato sería añadir un info.oza con la información documental en un conjunto indexado, pues eso permite la presentación tabular sin depender de estructuras de datos inflexibles.

comment:5 Changed 13 years ago by Víctor de Buen Remiro

(In [3949]) Refs #1368

comment:6 Changed 13 years ago by Víctor de Buen Remiro

Se ha creado una nueva función

Set TolPackage::Client::LocalInfo(Text name.version) 

que devuelve toda la información local disponible acerca de un paquete. Para ello utiliza un archivo info.oza ubicado en el directorio del paquete en el repositorio local y que contiene un conjunto indexado con todos estos elementos

  [[
    Text _.autodoc.name;
    Text _.autodoc.brief;
    Text _.autodoc.description;
    Text _.autodoc.url;
    Set  _.autodoc.keys;
    Set  _.autodoc.authors;
    Text _.autodoc.minTolVersion;
    Text _.autodoc.maxTolVersion;
    Real _.autodoc.version.high;
    Real _.autodoc.version.low;
    Date _.autodoc.releaseDate;
    Set  _.autodoc.dependencies;
    Set  _.autodoc.nonTolResources;
    Text _.autodoc.versionControl;
    Text _.autodoc.extra_info
  ]]

Los paquetes creados a partir de la nueva versión de TOL con los últimos cambios ya contendrán el info.oza en el archivo .zip por lo que al descomprimirse ya estarán disponibles.

Los paquetes viejos evidentemente no tendrán este archivo pero en tal caso, la propia función TolPackage::Client::LocalInfo lo generará la primera vez que se le llame o si se perdiera después de forma accidental. Para ello cargará el .oza localmente y extraerá la información pertinente, lo cual lógicamente puede llevar cierto tiempo en paquetes grandes pero al menos sólo habrá que hacerlo una vez.

No es necesario añadir el miembro _.autodoc.releaseDate ni el _.autodoc.dependencies en el código del paquete pues esa información se genera de forma automática en el momento de crear el paquete, y también a la hora de generar el fichero info.oza de un paquete viejo.

En este último caso se utilizará la fecha del fichero .oza del paquete, transportada a horario GMT, para generar el campo _.autodoc.releaseDate, para que funcione como hasta ahora.

La función TolPackage::Client::LocalLastCompatible utilizará también la información local de TolPackage::Client::LocalInfo y ya no necesita consultar el archivo VersSyncInfo.oza, y por tanto tampoco llamará a TolPackage::Client::RemoteUpdateVersSyncInfo

Los archivos de sincronización VersSyncInfo.oza y PackSyncInfo.oza se utilizarán ahora exclusivamente para tareas remotas de sincronización y actualización, que es para lo que tiene sentido usarlas.

comment:7 Changed 13 years ago by Víctor de Buen Remiro

(In [3951]) Refs #1368

comment:8 Changed 13 years ago by Víctor de Buen Remiro

(In [3953]) Refs #1368

comment:9 Changed 13 years ago by Víctor de Buen Remiro

Resolution: fixed
Status: newclosed

comment:10 Changed 13 years ago by Pedro Gea

(In [4613]) Refs #1502, #1374, #1373, #1371, #1368, #1257, #1206, #916
Se suben los cambios de la mejora a TolPackage.2 en carpetas y archivos auxiliares.

Note: See TracTickets for help on using tickets.