Unison in Fedora

Richard W.M. Jones rjones at redhat.com
Thu May 7 18:01:44 UTC 2015


On Thu, May 07, 2015 at 01:59:10PM -0400, Matthew Miller wrote:
> 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).

I think the problem is almost everyone would be using unison-legacy,
since that would be the only version compatible with the broader
ecosystem of Unison servers (by which I mean Debian).

So it doesn't really solve the "unnecessary updates" problem, if that
is really a problem.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org


More information about the devel mailing list