Bug#807019: tracking bin-num - broken unison due to binnmu upload
On 2016-01-04 17:24, Stéphane Glondu wrote:
Le 22/12/2015 00:38, Mehdi Dogguy a écrit :
The change done in unison 2.48 to overcome this looks pretty big...
I'm
not sure I'll be able/willing to provide a unison2.40.102 any more.
Moreover, this package was created to provide compatibility with
previous Debian releases, but another change in OCaml 4.02 makes it
incompatible anyway (both communicating unisons need to be compiled
with
the same version of OCaml in practice, which won't be the case any
more
when one side is Debian stable, and the other Debian testing). IMHO,
that's a design flaw in Unison that cannot be easily fixed.
A possible way out for stable (and old-stable) users could be to use
2.48
from backports, when 2.48 will be packaged and migrated to testing.
No, 2.48 from backports will be compiled with stable's version of OCaml
(4.01.0) whereas 2.48 from testing will (eventually) be compiled with
testing's version of OCaml (4.02.3), making both versions incompatible.
Oh, my understanding was that newer versions of Unison were not bound on
an OCaml version anymore and have had worked a synchronization format
which
will work well with any OCaml version. Sorry if this is not the case.
Personally, what I do when dealing with inter-release synchronization
involves using schroot... I heard of people copying binaries around,
and
others recompiling unison locally on one system. I don't know which
solution is the best. The situation sucks.
It is possible to backport OCaml 4.02.3 (and lablgtk2 :-/) and use that
from backports to build a compatible version of Unison. I realize this
is
a lot of work though.
Regards,
--
Mehdi
Reply to: