[Unison-hackers] OCaml version mismatch breaks Unison 2.48.4

Stéphane Glondu steph at glondu.net
Sat Sep 5 01:47:48 EDT 2020


Le 04/09/2020 à 16:00, Andrew Schulman a écrit :
>> Now, what I will do (I am the Unison maintainer in Debian) is embed the
>> OCaml version in the package name (e.g. unison-2.52+4.08.1) so that one
>> can have many combinations co-installed... but there will always be a
>> single OCaml version in the official Debian archive for a given suite.
> 
> I'm willing to do this too for Cygwin. For now I'm planning to package
> 
> unison2.48+4.04.2
> unison2.48+4.08.1
> 
> but that can change.
> 
> For the poor users who are trying to sync between, say, Cygwin and Debian,
> I think it would help if the package versions were the same in different
> distros. Then a user can just look and see that, for example,
> unison2.52+4.08.1 is available on both sides, and just install that and not
> have to worry about which OCaml versions are compatible with which others.
> 
> So if you know which versions you're planning to package for Debian, please
> tell us here so I can package the same ones. And if the Unison maintainers
> from other distros are also reading this list, it'd be good if we all
> packaged the same versions.

At the moment, in testing/unstable, there is "unison-2.48" (compiled
with OCaml 4.08.1). Since the next version of OCaml to be packaged in
Debian will be 4.11.1 and unison-2.48 does not compile with it, I think
I will let this unison-2.48 branch die and instead package the
soon-to-be-released 2.52.0 as "unison-2.52+4.11.1".

> BTW according to David Allsop on the Cygwin list[1], the first
> incompatibility in OCaml's marshaling came in OCaml 4.08, and the next one
> is coming in 4.11, although that one may not matter for Unison. So we
> probably only need one pre-4.08 and one post-4.08 package for each Unison
> version.

My plan is to stop using OCaml marshalling altogether. This may
introduce new dependencies, though, that I guess will have somehow to be
packaged for Cygwin. What's your take on this? I am thinking about
ppx_bin_prot (in opam, but has many dependencies), ppx_protobuf (in
opam, less dependencies, but does not support bigarrays so it won't work
on 32-bit) or maybe a custom ppx with no new dependencies.


Cheers,

-- 
Stéphane



More information about the Unison-hackers mailing list