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

2018-01-13 Thread Norbert Preining
> Thanks to Bruno's cooperation, the plan seems rather to generate a proper > ABI-like number (in this case the .mem hash code), which will allow us to > solve > this issue with minimal changes to both xindy and clisp packages. Indeed, that is the better solution. Thanks to everyone! Norbert

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

2018-01-13 Thread Sébastien Villemot
On Sat, Jan 13, 2018 at 01:55:58PM +0900, Norbert Preining wrote: > > I wonder if this can properly be achieved through dpkg triggers. > > Yes it can ;-) > > > That would be based on a specific dpkg trigger (e.g. xindy-buildmem). > > No, it would be a clisp trigger. clisp would look for some

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

2018-01-13 Thread Agustin Martin
2018-01-12 20:22 GMT+01:00 Agustin Martin : > I wonder if this can properly be achieved through dpkg triggers. > > That would be based on a specific dpkg trigger (e.g. xindy-buildmem). > The result should be that xindy.mem is removed on prerm and rebuilt > after fas contents

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

2018-01-12 Thread Norbert Preining
Hi all, > I wonder if this can properly be achieved through dpkg triggers. Yes it can ;-) > That would be based on a specific dpkg trigger (e.g. xindy-buildmem). No, it would be a clisp trigger. clisp would look for some place where new files are dropped, and rebuilds mems. If a new version

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

2018-01-12 Thread Agustin Martin
On Fri, Jan 12, 2018 at 11:06:11AM -0500, Sam Steingold wrote: > > * Sébastien Villemot [2018-01-12 12:30:26 +0100]: > > > >> > >> What if a user has installed xindy, with clisp as dependency, and then > >> upgrades > >> clisp to a different version, with a different

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

2018-01-12 Thread Sam Steingold
> * Sébastien Villemot [2018-01-12 12:30:26 +0100]: > >> >> What if a user has installed xindy, with clisp as dependency, and then >> upgrades >> clisp to a different version, with a different mem-hash? >> 1) Will the package manager report a conflict? > > Yes. > >> 2)

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

2018-01-12 Thread Bruno Haible
Sébastien Villemot wrote: > > 1) Will the package manager report a conflict? > > Yes. > > > 2) Will the package manager propose, as solution of this conflict, to > > install > > another binary package for xindy? Or will it only propose to remove > > xindy? > > Only two options will

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

2018-01-12 Thread Bruno Haible
Norbert Preining wrote: > this is the way the build process is set up by the upstream author, and > rewritting the whole build and distribution process *independently* from > upstream xindy is not an option AFAIU, the "virtual package with a hash code in its name" concept, proposed by Sébastien,

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

2018-01-12 Thread Bruno Haible
Sébastien Villemot wrote: > 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-", pretty much like we do for FASL version > format). Then, when xindy is compiled, it would acquire the dependency on

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

2018-01-12 Thread Sébastien Villemot
On Fri, Jan 12, 2018 at 12:25:08PM +0100, Bruno Haible wrote: > Sébastien Villemot wrote: > > 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-", pretty much like we do for FASL version >

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

2018-01-12 Thread Norbert Preining
Hi Bruno, thanks for your detailed answer! In my summary this means that .mem files are completely useless for third-party programs unless all fas files are shipped and .mem files always being rebuilt? If this is the case, we will have a "slight" problem with xindy, because this is the way the

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

2018-01-12 Thread Sébastien Villemot
[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

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

2018-01-12 Thread 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

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

2018-01-12 Thread 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

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

2018-01-12 Thread 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 - Date: Thu, 11 Jan 2018 22:42:00 +0100 From: Bruno Haible To: Sébastien Villemot