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 <br...@clisp.org> ----- Date: Thu, 11 Jan 2018 22:42:00 +0100 From: Bruno Haible <br...@clisp.org> To: Sébastien Villemot <sebast...@debian.org>, Norbert Preining <prein...@debian.org> Cc: Agustin Martin <agmar...@debian.org>, Sam Steingold <s...@gnu.org> Subject: please remove bump-fasl-loader-version.patch Message-ID: <2525153.Z8IsqQcaN0@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 -----
signature.asc
Description: PGP signature
