Re: multiple Unison packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: 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. Any chanche that most of the files are identical from version to version? In that case you could create a unison-base package and 4-5 small packages with maybe only the main executable. BTW: but does the protocol REALLY change ni EACH version? It seems that, even not wanting to be retro-compatible, it would have more sense to have a protocol version2 and require that THAT be identical instead... But oh well, if you say that developement has stopped, I guess there's no canche. BTW2: but if developement has really stopped, won't this program bit-rot pretty fast? - -- L a p o L u c h i n i l a p o @ l a p o . i t w w w . l a p o . i t / -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iEYEARECAAYFAkHhEssACgkQaJiCLMjyUvvAQwCfYuDi86KBdTupQpWlVnym+jrv 4UMAnif9+W8Q7dkGTkOPKsYmZrQhnp/+ =Z1fI -END PGP SIGNATURE-
Re: multiple Unison packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | I wonder which version other major distros are using. I can look into | that. If the major distros are all stuck in 2.9.1, then I guess I can | just package 2.9.1 and everyone will be able to talk to each other, at | least until the a href= | http://groups.yahoo.com/group/unison-users/message/2885;deadlock | bug/a kicks in. Gentoo has 2.9.1 marked stable for the major platforms and 2.10.2 marked testing. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4K+NpiWmPGlmQSMRAjxFAKC39/HXmzvmvrZrKlEUO77+7Z1yzQCgka57 NZsqJkWC2yeUMj6YW9zSV7Q= =D57W -END PGP SIGNATURE-
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 present. 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 released soon. 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 versions. 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 packages. Anyway, I'd appreciate some advice on these questions from either the Cygwin admins, or other maintainers who've tackled these issues before. Thanks, Andrew.
Re: multiple Unison packages?
[EMAIL PROTECTED] wrote: 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 present. The archive format is an on-disk thing, and not really relevant to network compatibility. The reason for the (overly) strict initial version check is to avoid any need for versioning or compatibility in the protocol that follows the initial greeting. 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 released soon. 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 versions. 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 packages. 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 packaging-unfriendly. Max.
