Hi Ralf, Ralf> The problem is that any software used to build packages in a Ralf> distribution (sid, in this case) must also be in the distribution. Ralf> Hence, providing builds of unison produced with different ocaml Ralf> versions implies having packages for different ocaml versions Ralf> in sid.
That's kindof what I thought, but if I understand correctly, unison in stretch must have been built with a different version of ocaml than the ocaml that's actually in stretch, which confusingly contradicts this? Stretch's unison is only compatible with other pre-ocaml-4.02 unisons, which suggests it was built with ocaml-4.01 — but stretch's ocaml is 4.02.3-9? This would seem to be confirmed by the fact that I had to downgrade ocaml to 4.01 on one of my (non-Debian, more recently updated) servers when building unison there, so that unison on my jessie and stretch machines could talk to unison on that server. Sorry if I'm being slow or missing the point here. If I've gotten that right, then the current version of unison on stretch is built with the "wrong" ocaml (i.e. not stretch's ocaml). The idea that it should be built with stretch's ocaml would then argue that technically unison on stretch needs to be updated to an ocaml-4.02 build. When that update rolls out, unison on stretch will become incompatible with everything that it currently works with (except itself, of course). So a warning release note would seem appropriate when that "upgrade" happens..? It would be nice if we could persuade upstream to at least give a more helpful error message when the incompatibility arises. Conrad
