Bug#246153: RFA: unison -- file-synchronization tool for Unix and Windows
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
Reply to: