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