On 2019-12-03 14:39:47 +0100, Stéphane Glondu wrote: > Le 03/12/2019 à 12:54, Vincent Lefevre a écrit : > > BTW, I think that "unison" should just be a metapackage depending > > on unison-debian<x>, where <x> is the Debian version (with adapted > > paths and executable names). That way, users could install both > > Unison from stable and from testing/unstable (unison just depends > > on libc6, so that this should be OK in practice).
Note: either unison-debian<x>, or some other unison-<y>, where <y> would depend on the OCaml base-version used (hardcoded in the build dependencies) and the version of the protocol used by unison (i.e. the two possible causes of breakage). The unison-debian<x> is fine as long as testing/unstable machines are upgraded at the same time, at least for the Unison packages, which is not too much to ask for the users. The unison-<y> solution may be better in the future if the choice of <y> is standardized across distributions and restricted to real incompatibility changes, so that the user does not have to provide a -servercmd option. > I like this proposal... > > This may make things easier for unison-all. > > ...but I still see no future for unison-all, as it would need to depend > on packages from stable and testing/unstable, wouldn't it? Yes, this is what it would do. But after all, perhaps let the user do things manually, because this is more complex: the user may also need to install the oldstable version. In particular, this will be needed when a new Debian/stable is released, as not all stable machines are upgraded at the same time (in my lab, the admins wait for several weeks, at least after the first Debian/stable update, then some machines are upgraded so that they and users can test them for regressions, then every machine is upgraded). So I would suggest to drop unison-all, and rename unison to make the current one co-installable with the one from Debian 10. -- Vincent Lefèvre <vinc...@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)