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

[Bruno Haible]

Hi Norbert,

> thanks for your email and your explanations. I am not clisp packager,
> but TeX Live (upstream and Debian) maintainer and thus also xindy
> maintainer.

I appreciate this work that you do. Nevertheless, your view of clisp .mem
file does not match reality:

1) The error "initialization file `lispinit.mem' was not created by this
   version of CLISP runtime" is UNRELATED to fas file versions.
   Here we are talking about the interface between the clisp (lisp.run)
   executable and the .mem file.

   Once you have a pair lisp.run and .mem files that matches, and you start
   using LOAD (of .fas files) and COMPILE-FILE, *then* the fas version
   becomes relevant as well. But simple applications (xindy is probably also
   in this category) don't use LOAD and COMPILE-FILE, they use just what
   is in the heap (= .mem file).

2) Mem file versioning does not work like version numbers that you can compare
   with >= or <=. It works like a number (hash code) that has to match via
   equality.

   For example, if in lisp.run the integer 5 is represented by the bit pattern
   0x10000005, and in the .mem file the integer 5 is represented by the bit
   pattern 0xC0000014, then the two will be incompatible. This is what
   the check is about (and about the set of add-on modules and their symbols).

   See also section "Image Portability" in
   https://clisp.sourceforge.io/impnotes/image.html#image-portability

3) 
> 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.

4)
> > Rule:
> >   When xindy is already installed on a user's machine and a newer clisp build
> >   gets installed that has a different .mem file format, the .mem file must
> >   be regenerated.
> 
> But this is completely unfeasable.

If you don't like this rule, or it cannot be implemented in Debian, then don't
use .mem files for packages other than clisp itself.

> 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.

> So the correct solution is as far as I see:
> * clisp provides some kind of API version that get *always* bumped when
>   incompatible changes to the representation etc (as you listed above)
>   occur.
> * xindy depends on exactly one of the API version, the one it was built
>   with. As long as there are updates to clisp without API changes the
>   mem file can be loaded and all is fine.
> * if there is an API change then there will be the usual transition of
>   APIs, that is all depending programs need to be rebuilt and
>   re-uploaded. That is complete standard in Debian
>   (see https://release.debian.org/transitions/ for current ones)

> it would be the easiest and most clean,
> and most common in general development practice, to have some kind of
> API version that is bumped.

This is wishful thinking. .mem files don't work like that.

> I am strongly opposing a solution that requires that the complete source
> of a package needs to be available on all users' computers

I did not say "the source". I said "the fas files".

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.

Bruno