Bug#886986: please remove bump-fasl-loader-version.patch

[Bruno Haible]

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