> 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
--
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 pl
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 on package postinst any
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 of
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 mem-hash?
> >> 1) Will the
> * 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) Will the package manag
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 be
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, i
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 t
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
>
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 bu
[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
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 "initializatio
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 iss
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 , Norbert Preining
Cc: Agustin Martin , Sam Steingold
15 matches
Mail list logo