Unison in Fedora

[Jujens]

On 05/07/2015 04:58 PM, Stephen John Smoogen wrote:
> On 7 May 2015 at 08:41, Kevin Fenzi <kevin at scrye.com> wrote:
>> On Thu, 7 May 2015 09:17:10 +0100
>> "Richard W.M. Jones" <rjones at 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).

This is because of these compatibility problems and the absence of
Unison 2.48.3 in the official repo that I packaged Unison 2.48 in copr.
I didn't go any further because I hadn't the time.

>>
>> ...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.

Maybe something like debian does : propose a unison (or unison-all)
package that always pull all the supported version of unison but let the
user install just a specific version.

> 
> 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.
> 
> 

I think after a certain amount of time it is reasonable to think that
the old version are not required any more. The question is how to decide
that?

-- 
Julien Enselme aka Jujens
http://www.jujens.eu/