This is the mail archive of the
mailing list for the Cygwin project.
Re: multiple Unison packages?
- From: "Max Bowsher" <maxb at ukf dot net>
- To: <Schulman dot Andrew at epamail dot epa dot gov>, <cygwin-apps at cygwin dot com>
- Cc: "Richard Lethin" <lethin at reservoir dot com>, "Gerrit Haase" <gp at familiehaase dot de>
- Date: Fri, 7 Jan 2005 20:46:25 -0000
- Subject: Re: multiple Unison packages?
- References: <OFBE789021.709C7C22-ON85256F82.005811DC-85256F82.006257D2@epamail.epa.gov>
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
The archive format is an on-disk thing, and not really relevant to network
The reason for the (overly) strict initial version check is to avoid any
need for versioning or compatibility in the protocol that follows the
Not that that changes the situation, of course. I'm just pointing out that
the network protocol could be incompatible, even though archive formats on
both ends were identical.
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.
Debian seem to be packaging just the current stable 2.9.1.
I suggest following their example, and trying to convince the upstream
maintainers that their current compatibility scheme is extremely