In unison 2.48.3, a native fsmonitor is introduced, with the new fsmonitor,
unison can impliment dropbox like sync on demand,following is quotad from
upstream NEWS:

     * File system monitoring:
          + The file watcher now fails when unable to watch a directory,
            rather than silently ignoring the issue.
          + File system monitoring: more robust communication with the
            helper program (in socket mode, the unison server will still
            work properly despite unexpected unison client
            disconnections).
          + A bytecode version of unison-fsmonitor is now produced by
            "make NATIVE=false"
          + Improved search for unison-fsmonitor

In Debian, unison is compile with NATIVE=true, so unison-fsmonitor is not
compiled, would you compile unison with NATIVE=true to build unison-fsmonitor?

Thanks,
Debian Release: stretch/sid
  500 unstable        192.168.2.12
    1 experimental    192.168.2.12
--- Package information. ---
Depends      (Version) | Installed
======================-+-===========
libc6         (>= 2.7) |


Recommends          (Version) | Installed
=============================-+-===========
ssh-client                    |
 OR openssh-client            | 1:7.2p2-2


Package's Suggests field is empty.

I think the reporter is incorrect in that what the changelog means is
that the monitor is build *also* when NATIVE=false from 2.48.3. At
least on my system the monitor is built, and it has NATIVE=true. I
haven't tested whether it'll build on a system that doesn't have
ocamlopt.

This means there are two monitors in unison, a python-based one and a
ocaml one. They seem to be functionally equivalent and unison seems to
pick the ocaml one if they're both installed.

This patch creates two new packages, one with each of them. They're
not ideal, in that they'll ship the whole doc/ directory like the
other packages do (but the packaging is rather complex and I haven't
been able to make it not do that without ripping it apart), and they
ship the helpers in /usr/bin instead of libexecdir; shipping them
there would require patching unison, which seemed a little extreme.

(actually, an easy way of putting them in /usr/lib would be to ship
the versioned binary there with the alternative symlink in /usr/bin...
should I do that?)

I'm interested in getting this integrated.  The Python version of
fsmonitor does seem to be flaky, the OCaml version seems better.  I
prefer it to be packaged in Debian.

I have updated John's patch above and based it on the current Git in
https://salsa.debian.org/ocaml-team/unison.git .

What else can I do to get there?

Le 19/02/2019 à 12:24, Benjamin Riefenstahl a écrit :

Thank you for your work!

Isn't python-foo (here, python-unison-fsmonitor) the naming convention
for stuff implemented in Python?

Also, why provide both versions? How, as a user, do I choose between
them? The descriptions are not very explanatory...


Cheers,

Stéphane Glondu writes:

No idea, is it?  ;-)

In theory both should work, I have not seen the author to prefer one or
the other (I have not looked very hard, though).  I tried to use the
Python script (it was ok for me to just install the one script from the
source), but it did not work reliably for me.  Once the packaging is
automated, the Python script is probably not needed any more in Debian,
so we could just drop that one from the patch.  Let me know, if I you
want a modified patch.

Hi Stephane,

See attached a new patch, that adds only the native fsmonitor.

Thanks, benny

Dear maintainer,

Will this get added to debian packages, so we can use unison-fsmonitor?

Thank you for all your work.

Hello,

Le 15/11/2019 à 18:02, Anton Avramov a écrit :

Sorry for not being responsive. I will update unison and try to add
unison-fsmonitor after the ocaml transition [1] is done.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941907


Cheers,

Le 21/03/2019 à 13:49, Benjamin Riefenstahl a écrit :

Is there any practical benefit in adding a new binary package?


Cheers,

Hi Stéphane,

What is the problem with binary packages?

If you are asking, why not the python version instead, I already said

To be more specific, the Python version did not work well enough in our
use case, while the OCaml does what we want.

benny

Le 03/12/2019 à 10:11, Benjamin Riefenstahl a écrit :

Binary packages have a cost. They are useful when they have additional
dependencies (that are optional for the main package) or when better
sharing is achieved (typical cases: -doc, or -common packages). Maybe
other cases.

My remark was not related to the python version. I was just wondering if
unison-fsmonitor could be provided by existing packages instead.

Since this needs to go through the NEW queue, I will take the
opportunity to create a package co-installable with the one in stable,
as Vincent suggested.


Cheers,

Hi Stéphane,

Ok, that's your domain, I don't know nothing about the policies here.

Sure.  My primary interest is just that it is installable somehow, so
that we do not have to continue to build our own at some point.  I was
just taking what John Lenton had already been offering and tweaking it.

Anyway, let me know if I can be of further help.

Thanks,
benny

Dear maintainer,

Can you give an update when should we expect this in debian?
Either as a standolne package or part of the main one

Thank you for all your work.

Le 22/07/2020 à 21:20, Anton Avramov a écrit :

My current roadmap is:
- create a new source package unison-2.48
- make meta-unison provide unison and unison-gtk with symlinks to the
  binaries provided by unison-2.48
- let the "unison" source package disappear
- create a new source package unison-2.51 (or whatever is the latest
  version at the time)
- ...
- build unison-fsmonitor in unison-2.51

and be done with alternatives. This new packaging scheme makes more
sense IMHO and will ease co-installability of multiple versions of unison.


Cheers,

What would be important would be to include the OCaml version number
in the unison package name, since it has an effect on the behavior.

I had to put unison 2.48.4-1+b1 to hold on my Debian/unstable machines
in order to be able to sychronize with Debian/stable (buster) ones.

Le 23/07/2020 à 17:35, Vincent Lefevre a écrit :

Right. I've already uploaded unison-2.48 to NEW, let's settle on that
first. I will add the OCaml version number in the next OCaml transition.

Any news on the unison-fsmonitor helper to be compiled and bundled with
the unison package ?

Please consider
https://salsa.debian.org/ocaml-team/unison/-/merge_requests/2

Hi Damian,

Thank you for the proposed patch. I tried using it, and it appears that
unison can't find the fsmonitor helper when it's named
"unison-$(ABI)-fsmonitor". Instead it should be named
"unison-fsmonitor-$(ABI)". See
<https://github.com/bcpierce00/unison/blob/ce6f66b048724687d716df33d5b47a4a5634b936/src/fswatch.ml#L268>

I think you need something like the attached patch (disclaimer: works on
my machine, that's as much testing as I did).

Have a nice day,
Fred.

Hi Frédéric,

thank you. I applied your patch on top, it works for me too.

Regards