On Thu, 7 May 2015 09:17:10 +0100 "Richard W.M. Jones" <rjo...@redhat.com> 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. kevin
pgpQtiUBuL4rD.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
