Unison in Fedora

[Richard W.M. Jones]

On Thu, May 07, 2015 at 02:19:27PM -0400, Matthew Miller wrote:
> On Thu, May 07, 2015 at 07:01:44PM +0100, Richard W.M. Jones wrote:
> > 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.
> 
> Well, presuambly, the frequently-changing package would be the
> non-legacy one which is under active development, right? So,
> unison-legacy wouldn't change often at all. Any non-critical fixes to
> it, including "graduation"of non-legacy to legacy, could be done in
> Rawhide, where mass rebuilds are likely to happen anyway, so all of the
> almost-everyone using the legacy package would only see a new package
> on system upgrade.
> 
> (Or is my logic here flawed?)

I don't think your logic is flawed, but there do appear to be more
builds for the combined "unison-legacy" package -- see my figures
here, assuming "unison-legacy" would cover the first three packages.

https://lists.fedoraproject.org/pipermail/devel/2015-May/210455.html

Anyway, I'd still prefer a single package, because I don't see the
frequency of updates as being an actual problem.

Another data item is the size of the Unison package:

  unison213     3875690 bytes
  unison227     4017698 bytes
  unison240-gtk 4491617 bytes

(These figures are all for F21)  So you're pushing out around 4MB per
update to each user, assuming you cannot get any savings from delta
RPMs.  That's one second of download time for most people in the
developed world.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top