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). > > ie, you have: > > unison package that ships all of Unison 2.13.16, 2.27.57, 2.40.128 > > Users install the one they need/want to use. > > you add 2.48.3 and all those users of the other 3 will get an update > with 0 changes. > > I don't think just adding new packages is that big a deal to save > everyone from this. > > kevin > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
