Unison in Fedora

[Matthew Miller]

On Thu, May 07, 2015 at 11:50:02AM -0600, Kevin Fenzi wrote:
> > 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 mean that anytime you say add a new version to it, or fix some minor
> packaging issue in just one, _EVERYONE_ with _ANY_ version will then
> get the update (even though it actually changes nothing on their
> system). 

So, how about _two_ packages, "unison" and "unison-compat" (or
"unison-legacy")? 

The "unison" would contain the latest code — as a name-versioned
subpackage. The "unison-compat" would contain all of the legacy ones —
also as subpackages.

The compat package would only need to be rebuilt when those have
security updates, or when a version moves from current to legacy
status. Hopefully security updates are infrequent (and I bet would tend
to cross multiple old versions if they affect any), and the shift from
current->legacy could be done only in rawhide (and therefore for
end-users only at Fedora release update time).



> 
> ie, you have: 
> 
> unison package that ships all of Unison 2.13.16, 2.27.57, 2.40.128
> 
> Users install the one they need/want to use. 
> 
> you add 2.48.3 and all those users of the other 3 will get an update
> with 0 changes. 
> 
> I don't think just adding new packages is that big a deal to save
> everyone from this. 
> 
> kevin



> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader