Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
On 29/12/2015 11:13, Alexander Wirt wrote:
> On Tue, 29 Dec 2015, Alexandre Rossi wrote:
>>>> The change done in unison 2.48 to overcome this looks pretty
>>>> big... I'm not sure I'll be able/willing to provide a
>>>> unison2.40.102 any more. Moreover, this package was created to
>>>> provide compatibility with previous Debian releases, but
>>>> another change in OCaml 4.02 makes it incompatible anyway (both
>>>> communicating unisons need to be compiled with the same version
>>>> of OCaml in practice, which won't be the case any more when one
>>>> side is Debian stable, and the other Debian testing). IMHO,
>>>> that's a design flaw in Unison that cannot be easily fixed.
>>> A possible way out for stable (and old-stable) users could be to
>>> use 2.48 from backports, when 2.48 will be packaged and migrated
>>> to testing.
>> The backport is indeed a nice way out of this, the rebuild is
>> straightforward (only tried for amd64).
This should be integrated in the backports.d.o repositories.
> Backports is not for fixing bugs in stable.
Should the description from backports.d.o be adjusted then? For now, it reads:
Backports are packages taken from the next Debian release (called "testing"),
adjusted and recompiled for usage on Debian stable.
Alternatively, can you please explain how this case doesn't fit?
We didn't need to backport Unison in the past because it used to work well
even with different OCaml versions. Now, this changed in 2.48 and we are not
able to offer sync between Stable and Testing machines anymore. In fact, the
"issue" was triggered by the fact that some internal structures changed in
some OCaml modules rendering Unison <2.48 unusable with recent OCaml version.
This is now fixed in Unison 2.48... hence the backport of Unison 2.48. But
there is nothing to fix in Stable...
My only doubt right now (about the backport) is about #805456. It would
be great to hear about the submitter before exposing Unison 2.48 to users