#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
Cc: | Jorge added |
---|
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
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
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:6 Changed 13 years ago by
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:9 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 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.