On 7 May 2015 at 08:41, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Thu, 7 May 2015 09:17:10 +0100 > "Richard W.M. Jones" <rjones@xxxxxxxxxx> wrote: > >> [Previous discussion here: >> https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495 >> ] > > (I guess I was cc'ed directly because I replied in that thread? There's > no need, I am still on this list. ;) > >> 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). > > ...snip... > >> Anyway, I think this situation is crazy. One reason is that in order >> to add the latest upstream Unison (2.48) I'm going to have to submit a >> new unison248 package[1]. And then if there's another version, I'll >> have to submit a new package for that. >> >> I think Fedora should have a single "unison" source package, and it >> should contain the multiple upstream branch sources and build >> different binary subpackages. The binary subpackages would have the >> same names as now (unison227 etc), making this a compatible update for >> existing Fedora Unison users. >> >> This way I only need to submit a single new package review, we can >> delete the unison2xx source packages, and there'll be a single place >> for unison in Fedora for ever more. >> >> Discuss ... > > Well, just as mentioned in the previous thread, if you do things this > way it means every user of any unison will have to get a useless update > everytime any version of unison in your combined package updates for > any reason. Thats pretty disruptive. I think the issue is that none of those versions are getting updates anymore. They are dead code... any fix that is going to be in one is probably going to be in all of them so they would all need it. -- Stephen J Smoogen. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
