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

[Sébastien Villemot]

[I have opened a bug in the Debian bug tracking system, #886986, so please keep
the corresponding email address in CC when replying]

Thanks Bruno for raising this issue.

I was unaware of the distinction between the FASL versions and the .mem
file hash.

Given the explanations given by Bruno, I am fully convinced that the patch
bumping the FASL versions should be dropped, and I will do so in a future
upload.

Still, we need to find a workable solution for software like xindy that build
a clisp image. See my answers below.


On Fri, Jan 12, 2018 at 09:50:29AM +0100, Bruno Haible wrote:

> > If the fasl-loader version is not the correct information, then clisp
> > should provide a way to distinguish updates that are harmless (without
> > changes to the internal representation) and those that are harmfull.
> 
>    As I said in the previous mail, this is not only about updates. It is also
>    about which configuration flags (--enable-portability or not) were used
>    to build clisp.

I agree with Norbert on that point. 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. 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).

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? Or that it's impossible to compute a meaningful hash?

> > Think about an API bump of the libc,
> > shoud *ALL* programs be recompiled *on*the*users*computers*? No, of
> > course not.
> 
> Linux distros runs ldconfig each time a new shared library gets installed.
> Rebuilding .mem files is a similar concept.

I would rather say that creating .fas files is similar to compiling (creating
dynamically-loadable .o files), and that creating the .mem files is similar to
linking them into an executable.

> If a package, such as xindy, did not use a .mem file, but instead xindy
> was a wrapper script that first loads a bunch of fas files and then executes
> some action based on the command-line arguments, you would be in the same
> situation: you would have to ship the fas files of xindy on the users'
> computers.
> 
> .mem files are really only an optimization of the startup time. It allows
> to reduce the startup time from something like 0.1 sec ... 1.0 sec to
> the range 0.001 sec ... 0.1 sec.

It would indeed be possible for xindy to live without the .mem file, and rely
only on the .fas files (for which correct versioning is already provided). But
this is up to Norbert to decide. I guess this would be the only practical way
if for some reason it were not possible to extract a .mem hash and convert it
into a virtual dependency.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-common-lisp-devel/attachments/20180112/a62af477/attachment-0001.sig>