Bug#990694: unison -addversionno option broken

[gpe92]

Package: unison-2.51+4.11.1
Version: 2.51.3-1+b1
Followup-For: Bug #990694

Dear Maintainer,

I've tried the workaround but it not works for me ...
Is there another workaround for this problem ?

BR

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unison-2.51+4.11.1 depends on:
ii  libc6  2.32-4

Versions of packages unison-2.51+4.11.1 recommends:
ii  openssh-client [ssh-client]  1:8.4p1-6

unison-2.51+4.11.1 suggests no packages.

-- no debconf information

Bug#990694: unison -addversionno option broken

[Vincent Lefevre]

Control: severity -1 important

On 2021-07-04 22:29:30 +0100, Ken Milmore wrote:
> The -addversionno option of unison attempts to invoke the same
> version of unison on the server as on the client, to prevent version
> mismatches.

It mainly allows one to select the expected version on the server
when several versions are installed (because of various kinds of
machines to synchronize).

> A workaround is to install the symlink manually, e.g.:
> 
> $sudo ln -s ../../bin/unison-2.51+4.11.1 /usr/local/bin/unison-2.51

This currently works, but will fail if the OCaml version is upgraded,
so that one has unison-2.51+X and unison-2.51+Y on the server,
with some clients having unison-2.51+X and other clients having
unison-2.51+Y. In short, this defeats the purpose of having the
OCaml version added to the version number for compatibility.
Thus...

> Suggested possible bug fixes:
> 
> 1) Install an additional /usr/bin/unison-2.51 symbolic link in the package, or

This solution is incorrect.

> 2) Modify the unison source to invoke "unison-2.51+4.11.1" instead
> of "unison-2.51" when the -addversionno option is supplied

This is the only correct way (the client needs to announce in some way
the OCaml version).

> (however this might break compatibility with other systems).

Such systems implicitly assume some fixed OCaml version. So there is
already no guarantee that they won't break anything.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#990694: unison -addversionno option broken

[Ken Milmore]

Package: unison-2.51+4.11.1
Version: 2.51.3-1

The -addversionno option of unison attempts to invoke the same version of 
unison on the server as on the client, to prevent version mismatches.

This facility seems to have been broken since Debian has augmented the version 
number of the binary with the ocaml library version.

Example to reproduce:



$touch test.src
$unison -addversionno test.src ssh://localhost/test.dst

Unison 2.51.3 (ocaml 4.11.1): Contacting server...
bash: line 1: unison-2.51: command not found
Fatal error: Lost connection with the server



The problem is that "unison-2.51" is invoked over the ssh connection, but the 
unison package no longer provides a binary or symlink with this name.
It does provide:

/usr/bin/unison-2.51+4.11.1 (binary)
/usr/bin/unison (symlink)

A workaround is to install the symlink manually, e.g.:

$sudo ln -s ../../bin/unison-2.51+4.11.1 /usr/local/bin/unison-2.51

Suggested possible bug fixes:

1) Install an additional /usr/bin/unison-2.51 symbolic link in the package, or

2) Modify the unison source to invoke "unison-2.51+4.11.1" instead of 
"unison-2.51" when the -addversionno option is supplied (however this might 
break compatibility with other systems).