This is the mail archive of the
mailing list for the Cygwin project.
multiple Unison packages?
- From: Schulman dot Andrew at epamail dot epa dot gov
- To: cygwin-apps at cygwin dot com
- Cc: Richard Lethin <lethin at reservoir dot com>, Gerrit Haase <gp at familiehaase dot de>
- Date: Fri, 07 Jan 2005 13:00:32 -0500
- Subject: multiple Unison packages?
Different versions of Unison won't talk to each other. For example, if
I have version 2.10.2 (current beta) installed on my local Cygwin host,
I can't synchronize with a server that's running version 2.9.1 (current
stable). The version numbers have to be exactly the same, or Unison
will issue an error message and quit.
The reason for the incompatibility, as I understand it, is that Unison's
archive format has changed from time to time. Data corruption could
occur, or so I'm told, if a user tries to synchronize using versions of
Unison that have different archive formats. In order to simplify their
code, the Unison developers decided just to require identical version
numbers before synchronization can take place. One can argue whether
that decision was the right one, but that's the way Unison works at
So the problem for Cygwin is how to accomodate these incompatible
versions. There are probably two or three versions of Unison in common
use today: 2.9.1 (current stable), 2.10.2 (current beta), and maybe
2.9.20 (previous beta). Others might come into use, however. There's
the previous stable version (2.8.something), which is probably still
running at a few sites, and there will probably be a new stable version
This leads me to two questions:
(1) How many of these different versions of Unison should I package? Of
course, Cygwin doesn't have to provide every version. But I do want to
provide the most commonly used ones, which might be anywhere from 2 to 4
More versions means that more people can use Unison, but also more
archive storage space (unison-2.10.2-3.tar.bz2 is 400KB,
unison-2.10.2-3-src.tar.bz2 is 515 KB), and more screen space in the
setup utility taken up by almost-identical packages.
Another consideration is that Unison comes in both CUI and GUI (GTK2)
versions. The current packages are CUI. I can't get the GUI version to
work yet in Cygwin, but if I do this could _potentially_ double the
number of Unison packages.
(2) If I'm going to provide just 2 or 3 versions, then should I split
them into separate packages (e.g. unison2.9.1 and unison2.10.2), or keep
them as previous, current, and test versions of a single unison package?
The latter approach is what I'm doing now, with unison-2.9.20-1 and
unison-2.10.2-3. It makes things simpler for users, but more
complicated for the Cygwin admins (e.g. when I upload 2.10.2-4, I'll
have to request that 2.10.2-3 be removed, and 2.9.20-1 be kept). It
also prevents users from installing more than one version at a time--
which come to think of it is probably a good reason to split the
Anyway, I'd appreciate some advice on these questions from either the
Cygwin admins, or other maintainers who've tackled these issues before.