unison @2.51.2_3 is actually version 2.31

[ShadSterling (Shad Sterling)]

unison @2.51.2_3 has never actually been version 2.51 (even though that version does exist), and now it seems to have changed to an even older version.

I've been using Unison to sync files on my mac with files on an OpenSUSE host, so I need to have matching versions on both hosts. Long ago that was easy, but after the update to OCaml 4.01 (in 2015?) I started having to jump through weird hoops to get matching versions.

Lately MacPorts unison @2.51.2_3 has actually been version 2.40, and I've been able to keep the same version on the OpenSUSE host by keeping my own copy of the obsolete OpenSUSE package. Yesterday or today MacPorts unison @2.51.2_3 has changed to be version 2.31, which is old enough that I can't find a copy of the old obsolete package for OpenSUSE.

MacPorts used to have unison @2.48 (that was actually Unison 2.48), and I just had to rebuild the package using matching OCaml; I think it was with a macOS update after which MacPorts dropped support for older GCC that MacPorts unison changed to package version 2.51 but Unison version 2.40 and I changed to installing the matching obsolete package on OpenSUSE. And now it looks like I can't do either.

Can I use macports to install Unison 2.40 or newer? How? What additional information about my setup would help?

[ryandesign (Ryan Carsten Schmidt)]

I'm not sure how this is happening for you.

As far as I can tell, the unison port installs the version it claims to:

$ sudo port -s install unison
--->  Computing dependencies for unison
--->  Fetching distfiles for unison
--->  Verifying checksums for unison
--->  Extracting unison
--->  Applying patches to unison
--->  Configuring unison
--->  Building unison
--->  Staging unison into destroot
--->  Installing unison @2.51.2_3+gtk
--->  Activating unison @2.51.2_3+gtk
--->  Cleaning unison
--->  Some of the ports you installed have notes:
  unison has the following notes:
    Unison has always suggested using the same version across machines accessing the the same files.
    If you want to keep the previous version, you can reactivate the previous version; see:

    https://trac.macports.org/wiki/howto/InstallingOlderPort
$ port contents unison | grep /bin/
  /opt/local/bin/unison
$ which unison
/opt/local/bin/unison
$ /opt/local/bin/unison -version
unison version 2.51.2 (ocaml 4.08.1)

[ShadSterling (Shad Sterling)]

After removing MacPorts Unison, installing a non-MacPorts Unison, then reinstalling Macports unison, it looks like /opt/local/bin/unison is invoking the non-MacPorts Unison:

$ port installed unison
Password:
The following ports are currently installed:
  unison @2.51.2_3+aqua (active)
$ which unison
/opt/local/bin/unison
$ /opt/local/bin/unison -version
2020-08-26 12:48:33.956 Unison[47475:452295] Calling nonGuiStartup
unison version 2.40.69
$ ls -al /opt/local/bin/unison
lrwxr-xr-x 1 root wheel 55 Aug 26 11:27 /opt/local/bin/unison -> /Applications/MacPorts/Unison.app/Contents/MacOS/cltool
$ /opt/local/bin/unison -unknownoption

... usage message ...

/Applications/Unison 2.40.69.app/Contents/MacOS/Unison: unknown option `-unknownoption'.
$

Why would MacPorts Unison be calling another Unison rather than running itself? Is there some setting I need to change?

[ryandesign (Ryan Carsten Schmidt)]

Aha! You are using the +aqua variant. I was using the +gtk variant.

With the +gtk variant, the port installs only a single file: /opt/local/bin/unison, the real unison program. Running it works normally.

But with the +aqua variant, it installs a macOS application bundle. That app bundle also contains a command line utility called cltool, and the port symlinks it to /opt/local/bin/unison. It turns out that tool attempts to find the real unison program by using the macOS launch services database, looking up the app by its bundle identifier, but if you've installed multiple apps with that identifier (one with MacPorts, one outside of MacPorts), who knows which one it will pick.

​https://github.com/bcpierce00/unison/blob/master/src/uimac/cltool.c

We could patch that to refer directly to the copy of Unison that MacPorts installed, since we know where that is.

[ryandesign (Ryan Carsten Schmidt)]

In 557b6a486615f3b87810e01fb02e0ac9abf03933/macports-ports (master):

unison: Ensure we launch the MacPorts unison

Change ${prefix}/bin/unison from a symlink to cltool to a shell script wrapper
that launches the application's main executable. cltool's main purpose is to
find the application via Launch Services, but if the user has multiple copies
of Unison installed, Launch Services might not return the one installed by
MacPorts and that would be confusing.

Closes: #61060

[ShadSterling (Shad Sterling)]

Ok, when I run /Applications/MacPorts/Unison.app/Contents/MacOS/Unison I get this error:

application requires at least OS X version 10.15.0 (10.15), but is being run on 10.14.6 ( 10.14.6/18G6020), and so is exiting.Abort trap: 6

Why is the MacPorts I installed on 10.14 building things for 10.15?

[ryandesign (Ryan Carsten Schmidt)]

Hmm, I don't see that problem; it launches fine on my 10.13 system. But it's a different problem from the one this ticket was about. Could you file a new ticket?

[ryandesign (Ryan Carsten Schmidt)]

That new ticket is #61081.