Sébastien Villemot wrote:
> The right solution would be to extract the
> hash for the .mem format when compiling clisp, and then turn it into a virtual
> package (like "clisp-mem-<HASH>", pretty much like we do for FASL version
> format). Then, when xindy is compiled, it would acquire the dependency on that
> virtual package, with the exact same hash.
OK, I can implement this. It would be two command-line options:
clisp [-K linkingset] --mem-hash Prints the expected hash of mem
files
clisp [-K linkingset] --mem-hash-of MEM-FILE Prints the hash of the
particular mem file
> Bruno, you said in you first message that clisp "does not currently provide a
> hash code". Does that mean that the information is somewhere but not exposed
> in
> a friendly way?
I meant that these command-line options are not yet implemented.
However, we need to think through the whole user experience.
> When a new version of clisp is
> uploaded, if the .mem format changes for whatever reason, then we would know
> that xindy needs to be recompiled (because the dependency would be broken).
What if a user has installed xindy, with clisp as dependency, and then upgrades
clisp to a different version, with a different mem-hash?
1) Will the package manager report a conflict?
2) Will the package manager propose, as solution of this conflict, to install
another binary package for xindy? Or will it only propose to remove xindy?
Bruno
