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

[Norbert Preining]

Hi Bruno, hi all,

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 allow myself to slightly disagree with your analysis.

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

In this case there should be a different fasl-loader-version be
employed.
The problem before was that although the internal representation
changed, the fasl-loader version did NOT change.

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.

The same happens with libraries and API versions all around Debian and
other distributions.

You propose:
> 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. Think about an API bump of the libc,
shoud *ALL* programs be recompiled *on*the*users*computers*? No, of
course not.

Therefore there are versions and the fasl-loader was used in this way.

There are changes in the API of libraries without a version bump, and
that always create a huge set of problems.

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)

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

That is indeed a problem, but it was introduced to the internal changes
without API version bump. Although this is a very unfortunate situation,
it is not something we as maintainers can or should pose our decisions
upon.

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

I am strongly opposing a solution that requires that the complete source
of a package needs to be available on all users' computers and programs
need to be rebuild on updates.

Please see my suggestion above, 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.

All the best

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc.     +    JAIST     +    TeX Live     +    Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13