[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#946046: not fixed



On 2020-08-08 09:53:21 +0200, Stéphane Glondu wrote:
> Le 08/08/2020 à 03:25, Vincent Lefevre a écrit :
> > The wontfix does not make any sense. The unison-all package is
> > described as follows:
> > 
> > Description: file synchronization tool (all console versions)
> >  This is a metapackage that depends on all supported console versions
> >  of Unison, a file synchronization tool.
> >  .
> >  Each of the supported versions uses a different protocol version;
> >  installing this metapackage ensures the ability to synchronize with
> >  old systems.
> > 
> > See the latest sentence. That's the *only* purpose of the unison-all
> > metapackage.
> 
> Ah right, the "ability to synchronize with old systems" is not correct
> and never will be.

This was correct in the past and really allowed me to have old unison
versions automatically installed. I suppose that either the unison
data formats in the protocol did not depend on the OCaml version at
that time, or it was not needed to rebuild the package after the
Debian release, so this was working in practice.

> For me, the purpose of unison-all is just to have all supported
> versions. For now, there is only one, but there could be many.

I think that this is of little interest if you can't guarantee
synchronization with the previous stable release at least (I
mean between 2 stable releases, or between the current stable
and unstable/testing).

> I accept this bug as an error in the description. Severity serious
> for this seems overreacted, don't you think?

I don't see this as an error in the description in the sense that
users probably installed unison-all to do synchronization between
2 releases, and starting with bullseye (currently unstable), this
is failing. This makes using this package useless, which is RC.

And note that worse than that, only the fact that trying to
synchronize with buster may currently corrupt the archive files
(as I could see). This requires the user to remove these files,
and though unison will not lose any data (in some sense) from a
state with no archive files, fixing the mess needs to be done
manually, and this can be difficult and take much time.

> > So, either you are able to fix the issue in some way via unison-all
> > (I can see only a rather ugly solution, though the end user would
> > not see the ugly part), or the issue cannot be fixed in a clean way,
> > and the unison-all package should just be removed from Debian as
> > being broken by design (co-instability of the stable versions and the
> > unstable version should be sufficient, without needing unison-all),
> > which is probably the easiest was to fix this bug.
> 
> So you think that having a metapackage just to install all supported
> versions is useless? Or even misleading? Then, I will remove unison-all
> and unison-all-gtk.

Yes, this is really misleading. While "ensures the ability to
synchronize with old systems" is clear enough (if it works), the
notion of "supported versions" is confusing, because the user will
have to ask himself whether this means he can synchronize with
older systems. It is better to document in the default package for
the current distribution that if the user wishes to synchronize
with an older distribution, he will have to install the version
from this distribution if it is different (the version being
composed of the version of the unison source and the version of
OCaml used to build unison).

Note: This applies between 2 Debian distributions, which is rather
easy via /etc/apt/sources.list, and with a non-Debian distribution,
the user will have to find a working pair of binaries anyway.

-- 
Vincent Lefèvre <vincent@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)


Reply to: