On Thu, May 31, 2018 at 8:32 AM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
Previously discussed several times, most recently:
* 2015 https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/
* 2011 https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495
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
separate packages:
* 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
branch.
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
spec file.
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.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/LUJRS5TUM7UQSMN2HEZPSDGLMAEJXYLE/
