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