Le 02/11/2017 à 01:30, Vincent Lefevre a écrit : >> This is a known issue, and not easy to fix. Upstream is not interested >> to make unison compatible with other versions of itself (or same version >> compiled with another version of OCaml): Unison is designed to work only >> with the same version, period. > > I thought this was only for major versions. Anyway, there's still > the workaround that was used in past Debian releases (e.g. jessie): > provide the version from the previous release too, then make the > unison-all package depends on both packages. I've just submitted > a RFP bug for unison2.48.3: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880541 > > IMHO, the current unison package should not enter testing before > unison2.48.3 is available, or this would annoy users who synchronize > between testing and stretch (AFAIK, synchronization between > sid/testing and jessie was working too before this upgrade).
The issue here is the version of ocaml used to compile unison. They must coincide on both sides. (Actually, it is a change in ocaml 4.02 that made unison incompable with itself when the version of ocaml differs, that explains why we could provide "compatibility" packages before.) Packaging unison2.48.3 won't solve the issue, since it would be compiled with today's ocaml, therefore it would be incompatible with the version in stretch. The way unisonX.YY.Z used to be packaged relied on the fact that the version of ocaml didn't matter, which is no longer true. And packaging multiple versions of ocaml just for unison is something I'm not willing to do. To synchronize between multiple releases of Debian (or Ubuntu), I use schroot on one side so that both sides are identical. I know other people directly copy the binary (the package or the executable) of one side to the other. I know this is inconvenient, but I find it more convenient than removing unison from Debian altogether. Cheers, -- Stéphane
