Debian breaking Unison (again)
Congratulations – Debian/sid now contains a unison binary that is incompatible with Debian/buster, the stable release. That means, everyone who relies on unison for file synchronization across servers (running buster) and development machines (running sid) is now busted. Trying to use the new binary from sid on buster also doesn’t work, due to GLIBC incompatibility.
For now the only solution I see is using the versions from Debian/buster and hold them, never to be upgraded for the next 2 years. At least that worked for me.
And BTW, the warning message that should be in NEWS(.Debian) didn’t make it into the binary builds …
Yup, I know your pain. I stopped using unison years ago because it regularly broke synchronization between debian stable and debian testing. Sometimes there was a unison-$SOMEOLDVERSION binary provided to work around it, but all in all at some point it became too much trouble for me to have to roll a dice after each apt upgrade of testing, to see if I had to update my scripts that invoked unison 🙁
But what else do you use for two-way sync? BTW, the situation is even more fu%&ed up now, since even with the bit-wise same binaries on two sid machines, the connection terminates, while connecting to my server running buster (with again the bit-wise same binary) there are no problems. I am really running out of ideas.
Unfortunately, upstream unison seems to be well aware but doesn’t consider it a problem …
Depending on the use case something like Syncthing could serve as a viable alternative? But I have to say I’ve found Unison tremendously useful since I first discovered it over a decade ago. Luckily I’ve only only been really bothered by the incompatible binary problem, and then there was a dedicated old version package to work around the issue.
“only once”, not only only. 😉
Indeed, I have been using unison since, I don’t know, 20(?) years, and it is the one most important tool I use from the say “devops” group.
Good that you had that experience only once, I remember it more or less from each Debian release change 🙁
Here is another upvote for Syncthing. Amazing piece of software! I have used Unison before, then Lsyncd (really good) and currently Syncthing.
unison is the only peace of software that I don’t write code for, but still compile
I guess this is what I have to do, too, but it wouldn’t help in this case, either. The problem is that the OCaml libraries have been updated (btw, minor version update – never heard about semantic versioning it seems) and that changed something in unison so that it cannot communicate anymore with a the same version build on a different OCaml. How disappointingly bad engineering this all is.
Ouch.
I guess, for Debian to address this, we would need overlapping Ocaml version windows over pairs of adjacent releases. And it looks like Ocaml don’t bump the major version when they break the API; there’s a minor bump between stretch→buster so I guess packaging “ocaml4.05” and “ocaml4.09” would have been a feasible, if ugly, approach, but we’d also need to have overlapping windows of the downstream tools too, or how would they ever migrate unison up from 4.05…
What a total mess!
Yeah indeed, the mess is with Ocaml which cannot do proper versioning. But the devs of ocaml and/or unison should be aware of that, in particular with such an important tool as unison, where we need backward compatibility with at least the stable release. I carry old binaries for old-stable even, since some servers (not mine) are still on old-stable. Huge pain.
Fixed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946041
Well, the “fix” is to document it in the NEWS file, not a real fix for the problem, right?