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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
