On Fri, 2004-04-30 at 09:10, Jens Schmalzing wrote: > Dear Rob, > > I've been a user of unison for quite some time, and therefore more > than happy to answer your request for adoption of the package. I'm > not sure whether I fully understand your intentions for the gtk -> > gtk2 transition, but this looks like it can be worked out. What > puzzles me, however, is the list of normal bugs - all of them look > like they should have been forwarded upstream. Any reason for not > doing this? > > Regards, Jens.
I'm CCing the debian-ocaml-maint list on this e-mail because Sylvain Le Gall from the pkg-ocaml-maint team on Alioth asked me on ICQ if the team could take over the package. Either is fine by me, so you guys should discuss it amongst yourselves and CC the bug & mailing list to keep it recorded. The bugs are all fairly simple and should be fixed or forwarded - I've just not had much time to dedicate to Debian stuff due to university work, and that time I do have goes to Gaim (I'm lucky enough to have a conscientious co-maintainer for gift). If you're not a developer I've not got a lot of time, but maybe you could hook up with someone on the ocaml-maint team, if not join it. The problem with unison is that as far as I am aware, each version is protocol incompatible with all other versions - the protocol version is the application version - although the text and ui versions of the same version speak the same protocol obviously. The gtk2 version is appealing, but merely upgrading the package from 2.9.1 to 2.9.20 will mean that you can no longer synchronise with woody systems, and I feel this breaks the spirit that we try to remain compatible with at least one previous release. Hence we should always try and keep two versions of unison in unstable - the version that's latest upstream, and the version that's in our stable release. For each of these, there is a gtk and a non gtk version, and they should all be concurrently installable to not prohibit any direction of synchronisation with woody boxes. Accordingly we will need three source packages: * unison, which builds two transition binary packages "unison", which depends on unison-2.9.20 | unison-2.9.1, and "unison-gtk" which depends on unison-gtk-2.9.20 | unison-gtk-2.9.1 - these packages could also be arch: all and hence usefully contain the documentation which is not put in the source tarballs by upstream * unison-2.9.1, which builds two binary packages "unison-2.9.1", which provides /usr/bin/unison-2.9.1 and registers it as an alternative for /usr/bin/unison, and "unison-gtk-2.9.1", which provides /usr/bin/unison-gtk-2.9.1 and registers it as an alternative for /usr/bin/unison-gtk * unison-2.9.20, which is the same except with the appropriate version, and registers a higher priority than the version in woody so that it is the default Unison has a command-line option to specify a versioned binary to use on the remote end of the connection, so I believe this packaging and naming scheme will allow concurrent installation of all necessary versions of unison to, eg, synchronise between a sid machine with 2.9.1-gtk and a woody machine with 2.9.1, or synchronize from a woody machine with 2.9.1-gtk to a sid machine with 2.9.1. Hopefully that's clear and I'm not talking nonsense - it seems a reasonable strategy to me. When new upstream releases come out, the middle version that's not in stable can be removed. People with testing can stick with the ver in stable, or pull the new one from unstable. Regards, Rob
