Hello, On Sun, Oct 22, 2006 at 09:24:03PM +0200, Helge Kreutzmann wrote: > Package: unison > Version: 2.13.16-5 > Severity: normal > > Up to todays upgrade of unison, connecting with sarge clients (by > setting the appropriate communication version) worked. Now I get: > Fatal error: Received unexpected header from the server: > expected "Unison 2.13\n" but received "Unison 2.9.1\n\000\000\000\000", > which differs at "Unison 2.9". > This can happen because you have different versions of Unison > installed on the client and server machines, or because > your connection is failing and somebody is printing an error > message, or because your remote login shell is printing > something itself before starting Unison. > > To get it working, I needed to install unison2.9.1 *and* run > update-alternatives --config unison > > An upgrade should not break a working setup like this (requiring > installation of additional software *and* reconfiguring). I vaguely > remember having done this when switching to Testing quite a while back > already. > > At least a NEWS.Debian should tell users what to do. And it should not > occure every time a new version of unison is released (i.e., a new > version should be installed additional at with lower priority in > update-alternatives), activating it should be left to the user. >
I am ok with you concerning documentation issue : - i will add what is required in NEWS.Debian, - i will add update-alternatives to the documentation, Concerning, the breakage and the lower priority, i don't agree : the package don't break the local configuration. It breaks the configuration between a not up-to-date system and an up-to-date system. To my mind, the most common case is to use unison between only "unstable" systems or only "stable" systems. If an additional manipulation is required to do the job for a mix of stable and unstable system, i don't think it is a great deal. There is also the fact, that doing what you propose will end up by never trying the newest version of unison... And also, that this way of packaging was made on purpose, because unison2.9.1 is ONLY for compatibility (i won't fix any bugs on it and i will ask for his removal from etch). 2.9.1 is not a branch of unison, it is an abandonned version, the upstream author won't fix any bugs on it either... I am the packager, and i reflect the way the upstream author manages version... I could not keep version, he chooses to abandon... So, what i propose is to keep the actual way it work and only change some documentation. Kind regard Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
