Bug#819341: [unison] Please build unison-fsmonitor

[Liang Guo]

Package: unison
Version: 2.48.3-1
Severity: wishlist

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,



--- System information. ---
Architecture: amd64
Kernel: Linux 4.3.0-1-amd64

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.




--
Thanks and Regards,
--
Liang Guo
http://bluestone.cublog.cn

[Benjamin Riefenstahl]

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?

[Stéphane Glondu]

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

[Benjamin Riefenstahl]

Stéphane Glondu writes:
> Isn't python-foo (here, python-unison-fsmonitor) the naming convention
> for stuff implemented in Python?

No idea, is it? ;-)

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

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.

[Benjamin Riefenstahl]

Hi Stephane,

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

Thanks, benny

[Anton Avramov]

Dear maintainer,

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

Thank you for all your work.

[Stéphane Glondu]

Le 21/03/2019 à 13:49, Benjamin Riefenstahl a écrit :
> See attached a new patch, that adds only the native fsmonitor.

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


Cheers,

--
Stéphane

[Benjamin Riefenstahl]

Hi Stéphane,

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

What is the problem with binary packages?

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

> The Python version of fsmonitor does seem to be flaky, the OCaml
> version seems better. I prefer it to be packaged in Debian.

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

benny

[Stéphane Glondu]

Le 03/12/2019 à 10:11, Benjamin Riefenstahl a écrit :
>> Is there any practical benefit in adding a new binary package?
>
> What is the problem with binary packages?

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.

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

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,

--
Stéphane

[Benjamin Riefenstahl]

Hi Stéphane,

> Binary packages have a cost. They are useful when [...]

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

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

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

[Anton Avramov]

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

[Stéphane Glondu]

Le 22/07/2020 à 21:20, Anton Avramov a écrit :
> Can you give an update when should we expect this in debian?
> Either as a standolne package or part of the main one

I am planning to change the packaging structure of Unison in Debian.

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,

--
Stéphane

[Vincent Lefevre]

On 2020-07-23 17:08:48 +0200, Stéphane Glondu wrote:
> I am planning to change the packaging structure of Unison in Debian.
>
> 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.

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.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Sylvain Leroy]

On Fri, 24 Jul 2020 07:49:22 +0200 =?UTF-8?Q?St=c3=a9phane_Glondu?=
<glo...@debian.org> wrote:

> Le 23/07/2020 à 17:35, Vincent Lefevre a écrit :
> >> I am planning to change the packaging structure of Unison in Debian.
> >>
> >> 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.
> >
> > 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.
>

> 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 ?

--
Sylvain Leroy
Président Eternilab
https://www.eternilab.com

[Damian Lukowski]

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