On Thu, May 31, 2018 at 8:32 AM Richard W.M. Jones <rjo...@redhat.com> wrote:
> Previously discussed several times, most recently: > > * 2015 > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/LUJRS5TUM7UQSMN2HEZPSDGLMAEJXYLE/
