Unison 2.32 port

[rwilcox (Ryan Wilcox)]

Unison is a file synchronization tool which has a client and server component. Both of these components must have the same version number in order for Unison to operate.

Which means that if your remote host has Unison 2.32.52 that your local machine must also.

This port file and relevant patches restore Unison 2.32.52 to the Macport port tree. Most of this work was done by digging back into SVN and getting the files back, which some small modifications due to bit rot.

[rwilcox (Ryan Wilcox)]

patch for the files directory (patches Makefile)

[rwilcox (Ryan Wilcox)]

patch for the files directory (patches update mli script)

[ryandesign (Ryan Carsten Schmidt)]

Thanks.

You've named this new port unison32, but since the version of this port is 2.32.52 it seems best to name the port unison232. Does that sound ok to you?

Since this situation of needing the same version of unison on the client and server seems destined to continue, we should replace the existing unison port with a unison240 port, and in future add new ports if new versions of unison are released. The version of unison240 should be 2.40.63, since that is the stable version, not 2.40.65, since according to #35116 that one is not stable and does not work right. The new unison232 and unison240 ports must have their install locations changed so that they do not conflict with one another. The existing unison port can be kept as a stub port marked as replaced_by unison240 to facilitate upgrades.

The whitespace of the existing unison port (and this unison232 port) does not conform to the modeline. I'd like to make an initial commit to fix the whitespace to conform to our guidelines. Then we can copy it to make the new ports.

You indicated you'd like to maintain this new unison232 port. Would you like to maintain the new unison240 port and the unison stub port as well? Since you are not a committer it would make things easier if we would make the ports openmaintainer as well, so that we would not need to ask your approval before making minor changes such as version updates. Let me know if that's ok with you.

There are some probably unintended differences between this new unison232 port and the existing unison port, such as the missing license line and the missing description of the aqua variant. The livecheck of the new unison232 and unison240 ports should be changed to only find stable versions of those respective branches, or turned off if no new releases of that branch are expected.

I will investigate whether it might be simpler to implement the unison232 and unison240 ports as subports of the unison port; this would eliminate the need to manually keep separate portfiles synchronized.

I can work on these various issues tomorrow, if you have no objections, and I'll attach new Portfiles here for your contemplation.

[rwilcox (Ryan Wilcox)]

Replying to ryandesign@…:

Thanks.

You've named this new port unison32, but since the version of this port is 2.32.52 it seems best to name the port unison232. Does that sound ok to you?

Absolutely!

Since this situation of needing the same version of unison on the client and server seems destined to continue, we should replace the existing unison port with a unison240 port, and in future add new ports if new versions of unison are released.

Agreed.

The new unison232 and unison240 ports must have their install locations changed so that they do not

conflict with one another.

I'm curious what would happen if you had two unison versions installed at the same time. For example, are there any changes to the settings and/or various archive formats that makes having two versions of Unison simultaneously installed a Really Bad Idea.

Right now my workflow mostly has me running Unison 232, but every once in a while I deactivate and activate unison240... which may disprove my point.

You indicated you'd like to maintain this new unison232 port. Would you like to maintain the new unison240 port and the unison stub port as well?

Sure. I've been using Unison something like 20 times a day for the last year or so, so it's a pretty important part of my toolchain at this point. Setting the openmaintainer would be awesome also.

There are some probably unintended differences between this new unison232 port and the existing unison port, such as the missing license line and the missing description of the aqua variant.

Yes, if anything happened in Macports convention since the last time Unison 2.32 was in the tree, probably those bits in the Portfile have rotted too.

I will investigate whether it might be simpler to implement the unison232 and unison240 ports as subports of the unison port; this would eliminate the need to manually keep separate portfiles synchronized.

I had no idea Macports could do that now. That might be interesting.

I can work on these various issues tomorrow, if you have no objections, and I'll attach new Portfiles here for your contemplation.

Thank you very much, that sounds great to me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to rwilcox@…:

The new unison232 and unison240 ports must have their install locations changed so that they do not

conflict with one another.

I'm curious what would happen if you had two unison versions installed at the same time. For example, are there any changes to the settings and/or various archive formats that makes having two versions of Unison simultaneously installed a Really Bad Idea.

That's a good question. We could further modify each version of unison to give each its own settings file / config area, or whatever it is that unison has.

My thought was just that if the client and server versions must match, then who's to say a user wouldn't have one server they need to communicate with that uses one version, and a different server that uses a different version? Thus they would need to have both versions of the client software on their computer installed at the same time.

It's also implied by the naming convention: in MacPorts, multiple ports for the same software but different version numbers, like xxx1 and xxx2, are assumed to be simultaneously installable.

[rwilcox (Ryan Wilcox)]

Replying to ryandesign@…:

Replying to rwilcox@…:

The new unison232 and unison240 ports must have their install locations changed so that they do not

conflict with one another.

I'm curious what would happen if you had two unison versions installed at the same time. For example, are there any changes to the settings and/or various archive formats that makes having two versions of Unison simultaneously installed a Really Bad Idea.

That's a good question. We could further modify each version of unison to give each its own settings file / config area, or whatever it is that unison has.

Let me go do some research and ask on the Unison mailing list and see what they say :)

My thought was just that if the client and server versions must match, then who's to say a user wouldn't have one server they need to communicate with that uses one version, and a different server that uses a different version? Thus they would need to have both versions of the client software on their computer installed at the same time.

It's a good question - I've been avoiding that issue by punting (activating / deactivating the proper port)... but maybe it's a problem that needs to be solved.

And maybe it makes sense to copy the route taken by python_select (??)

[ryandesign (Ryan Carsten Schmidt)]

I've looked into this a bit.

I see the port only installs a single file, the actual unison executable, as ${prefix}/bin/unison-${branch}, and then installs a symlink ${prefix}/bin/unison pointing to it. So we can very easily just not install the symlink, and leave that for a new unison_select port to do. As for settings, it seems to store things in ~/Library/Application Support/Unison. I am hoping we don't need to change this per-version since I'm not sure at the moment where to do it.

Given this naming of the executable, I might instead name the new ports the same (unison-2.32, unison-2.40), matching the naming recently used in the clang and llvm ports (clang-3.0, clang-3.1, etc.)

The port has two variants, x11 and aqua. Without the x11 variant, only a command line version of the program is built. With the x11 variant, a gtk2 GUI is added, but the command line version is still accessible, selectable with the -ui command line argument. I think it makes sense to make the x11 variant the default (default_variants +x11) that way the most full-featured version is installed by default. Users who don't want it can disable it (sudo port install unison -x11), now that MacPorts remembers disabled variants in the registry.

The aqua variant is not a variant at all in my mind, but a completely separate program. Using this variant doesn't install the command line version at all, but instead only installs an OS X GUI. I propose that we break the aqua variant out into its own subport so that a user could install both the OS X GUI and the command line version if desired.

There are multiple problems building the GUI on Mountain Lion (see years-old existing tickets) which I am in the process of hopefully correcting.

[ecronin (Eric Cronin)]

The aqua version is also fully usable from the command line if you pass "-ui text" to Contents/MacOS/Unison. The GUI has a menu option to install a symlink in /usr/bin (which should probably ideally be disabled in macports and a controlled symlink in $prefix installed instead).

[ryandesign (Ryan Carsten Schmidt)]

Oh! That might change my opinion of that variant. I haven't actually gotten it to build yet because I've been working on other things.

[ecronin (Eric Cronin)]

I wasn't totally accurate before. What they actually install is a compiled helper of some sort that looks up the bundle ID and then opens it. I think this is to handle moving the .app, but probably also because if you run /usr/bin/unison with no args it opens the aqua GUI, and with just a symlink it won't find its Resources. So maybe a similar wrapper is what's needed with +aqua.

I mostly use the CLI but the GUI is nice occasionally, so it would be a big plus if +aqua installed both. Up until the 2.40.65 issue I always just used to default no-gui variants and only discovered the aqua binary had CLI support when forced to switch to the upstream binary by macports being broken...

[ob+macport@…]

Cc Me!

[someuser12]

Cc Me!

[ecronin (Eric Cronin)]

Semi-dup of #14172. I'm about to push updates to 2.40.x to solve the current total breakage with anything other than other macports installed unisons.

I don't have time to develop and test versioned unison ports and unison_select for the /opt/local/bin/unison symlink, but that's probably the way to go. Any time a new release states that it broke archive compatibility a new port/subport is needed. Those tend to be any X.Y to X.Z releases, while the X.Y.a to X.Y.b releases are compatible...

Using the same config with two different versions of unison will lead to pain, but as long as you use separate config files two versions of unison can share Library/Application Support/Unison safely.

Aqua is still broken for me on Lion, and I didn't try getting UISTYLE=newmac09 working at all... I didn't add default_variants in this update since it drags in a bunch of X dependencies and I have no idea how many people actually use the X interface.

[ryandesign (Ryan Carsten Schmidt)]

Sorry, I got sidetracked and forgot about this update. I have some work in progress on this... would you like me to attach it or are you already working on your own update?

[ecronin (Eric Cronin)]

Oops. r100031 r100032 r100033 r100034. Hopefully they were minor/separate enough not to make merging your work too much of a pain. I believe there's a new major release coming within a couple weeks (which the new livecheck will detect), not sure if it will be an archive-incompatible one or not, but probably want to hold off on it until the work in this ticket is done if it is.

[ryandesign (Ryan Carsten Schmidt)]

No matter! Thank you for updating the port.

[rwilcox (Ryan Wilcox)]

Modifications to properly download, liveupdate this Portfile

[rwilcox (Ryan Wilcox)]

I've just added a new patch to this ticket, portfile-11-25-2012.diff.

Over the last few months this port was changed so that the download stage fails. This patch corrects the Portfile to download from the correct place.

It also should support live updating, based on work done to the standard unison (2.40.x) port.

[mf2k (Frank Schima)]

The port is currently at version 2.51.2.