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

[Sébastien Villemot]

Package: clisp
Version: 1:2.49.20170913-3

This bug was reported by Bruno Haible by private email, see below.

----- Forwarded message from Bruno Haible <bruno at clisp.org> -----

Date: Thu, 11 Jan 2018 22:42:00 +0100
From: Bruno Haible <bruno at clisp.org>
To: Sébastien Villemot <sebastien at debian.org>, Norbert Preining <preining at debian.org>
Cc: Agustin Martin <agmartin at debian.org>, Sam Steingold <sds at gnu.org>
Subject: please remove bump-fasl-loader-version.patch
Message-ID: <2525153.Z8IsqQcaN0 at omega>

Hi Sébastien,

In clisp for Debian 'unstable', there is a patch
bump-fasl-loader-version.patch, originating from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877223


--- a/src/constobj.d
+++ b/src/constobj.d
@@ -337,7 +337,7 @@
   /* The date of the last change of the bytecode interpreter
      or the arglist of any built-in function in FUNTAB or FUNTABR */
   /* when changing, remove legacy ABI! */
-  LISPOBJ(version,"(20100806)")
+  LISPOBJ(version,"(20100807)")
   LISPOBJ(machine_type_string,"NIL")
   LISPOBJ(machine_version_string,"NIL")
   LISPOBJ(machine_instance_string,"NIL")


Please remove this patch.
1) It does not reliably fix the original issue.
2) It has undesired side effects, unrelated to the original issue.

Ad 1):
The original issue was an error
  initialization file `/usr/lib/xindy/xindy.mem' was not created by this version of CLISP runtime

This error comes from src/spvw_memfile.d, and the clisp version that
created the .mem file and the clisp version that attempts to use the .mem
file disagree in
  - either the *object representation* (especially HEAPCODES vs. TYPECODES) [1],
  - or the set of add-on modules and their symbols.

The issue will reoccur when Sébastien uploads new clisp binaries
  - either from a new clisp version (I'm currently preparing a 2.49.70)
    that has a different heuristic for choosing the object representation,
  - or build with a different setting of --enable-portability (because
    on 32-bit platforms this also has an effect on the object representation
and the xindy.mem file remains unchanged.

Ad 2):
Assume a university installs clisp-2.50 on all its computers: from the Debian
packages on Debian machines, and from source on the other machines. (As a matter
of fact, the Math department of Utah university does exactly this.)
The Debian machines will write .fas files with a version stamp
  (SYSTEM::VERSION '(20100807.))
and the other machines will write .fas files with a version stamp
  (SYSTEM::VERSION '(20100806.))
The effect will be that users working in NFS-mounted directories will find that
their fas files from one machine don't work on some other machines. This would
be a MAJOR annoyance when working with clisp.


How to fix the original problem?

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.

clisp could (but does not currently) provide a hash code for the .mem file
format. Therefore - not knowing whether the .mem file format has changed or not -
the rule to be applied is:
  When xindy is already installed on a user's machine and a newer clisp build
  gets installed, the .mem file must be regenerated.

How to implement this rule, is Debian specific.

I don't think a 'dep:' link will be a maintainable solution. (This would
require that clisp provides a command that produces said hash code.)

Instead, how about this:
  - The binary package of xindy includes not only the .mem file but also
    the set of .fas files that gave rise to it.
  - The binary package of clisp contains a post-install trigger that will
    rebuild the xindy.mem file from its .fas files. (And likewise for all
    other packages that are in the same situation as xindy.)

Bruno


[1] https://clisp.sourceforge.io/impnotes/typecodes.html


----- End forwarded message -----
-------------- 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/ad5286c7/attachment.sig>