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
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader