[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
signature.asc
Description: PGP signature
