On Thu, May 31, 2018 at 8:32 AM Richard W.M. Jones <rjones(a)redhat.com>
Previously discussed several times, most recently:
Unison is a fairly widely used file synchronization package. Think of
it as a more efficient, multi-directional 'rsync'.
Unison has the unfortunate property that versions of Unison are not
compatible with each other unless they have the exact same major.minor
release. eg. Unison 2.40.128 is compatible with Unison 2.40.102, but
incompatible with Unison 2.48.3 (the latest upstream).
The reason that matters is you might be running Unison across multiple
machines, running different Linux distros, which have different
versions of Unison.
For this reason, Fedora packages three different Unison branches in
* unison213 (currently Unison 2.13.16)
* unison227 (currently Unison 2.27.157)
* unison240 (currently Unison 2.40.128)
* There was a "unison" package, but it is retired
We don't package the latest upstream versions (Unison 2.48.4,
Unison 2.51.2) at all.
Because of what I said above, it matters what Debian is shipping:
* unison 2.27.57
* unison 2.32.52
* unison 2.40
=> If you wanted to communicate between Fedora and Debian you could
use either 2.27 or 2.40.
It's not likely that Unison will use a stable, cross-version protocol
any time soon.
I'm proposing that we clear up this mess by creating a single unified
package called just "unison" which will build subpackages for each
version. It will contain multiple source tarballs for each major
Although this is very slightly dubious from a packaging point of view,
I believe it's the best solution here. It means we can build multiple
versions, we don't need to go through the new package review process
every time upstream releases a new major version, and it'll make
managing the package simpler at the cost of a somewhat more complex
If no one has any objections, I'll submit a unified unison package to
the new package process.
Are these packages parallel-installable (and do they need to be?) It seems
to me like this would be a FAR better solution as a module. You just have
branches for the major/minor releases and then ship module streams for each
one. They can be built and updated independently (rather than rebuilding
all of them each time any of them releases an update).
I can help you with this, if it's an approach you want to take.