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