[Bug 1169661] New: barrier isn't compatible with synergy
http://bugzilla.suse.com/show_bug.cgi?id=1169661 Bug ID: 1169661 Summary: barrier isn't compatible with synergy Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs@suse.de Reporter: martin.wilck@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I am happy that barrier is part of TW. But it should not set "Obsoletes" and "Provides" tags for synergy.
From barrier changelog:
------------------------------------------------------------------- Tue Apr 7 08:10:04 UTC 2020 - Tomáš Chvátal <tchvatal@suse.com> - Drop SUSE Firewall declarations - Do not use service but just utilize the download URL - Provide and obsolete synergy as we actual fork of it The last change causes synergy to be automatically deinstalled on all TW systems. This was a disruprtive move for environments where not all clients and servers can be changed to use barrier. The barrier protocol is incompatible with the synergy protocol. This is independent of encryption; it's simply due to differen "Hello" strings used in the protocol. Log snippets from synergy server and barrier client, without encryption:
cat /tmp/server.txt [2020-04-16T14:15:27] NOTE: new client disconnected [2020-04-16T14:15:28] NOTE: accepted client connection [2020-04-16T14:15:28] DEBUG1: saying hello [2020-04-16T14:15:28] DEBUG2: writef(Synergy%2i%2i) [2020-04-16T14:15:28] DEBUG2: wrote 11 bytes [2020-04-16T14:15:28] NOTE: new client disconnected
cat /tmp/client.txt [2020-04-16T14:15:28] DEBUG: Opening new socket: 4D8980F0 [2020-04-16T14:15:28] DEBUG1: connecting to server [2020-04-16T14:15:28] DEBUG1: connected; wait for hello [2020-04-16T14:15:28] DEBUG2: readf(Barrier%2i%2i) [2020-04-16T14:15:28] DEBUG2: readf: format mismatch: B vs S [2020-04-16T14:15:28] DEBUG: Closing socket: 4D8980F0
It can be seen that the client read "Synergy" while expecting "Barrier", and disconnected. There's no reason for the "Obsoletes:" tag. In fact, synergy and barrier can be nicely installed on one system at the same time, so we don't even need "Conflicts:". You just can't *run* both synergys and barriers in parallel (it might even be possible to run both on different ports, but I doubt it would work, at least not in the same graphical session). There's even less reason for the "Provides:" tag, because barrier does *not* provide a replacement for synergy, see above. For the time being, it should be up to admins whether they want to use one or the other. We can't expect people to migrate a whole data center (or home office, for that matter) just because of a single TW system being updated. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c1 Martin Wilck <martin.wilck@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tchvatal@suse.com --- Comment #1 from Martin Wilck <martin.wilck@suse.com> --- SR 794595. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 Tomáš Chvátal <tchvatal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|screening-team-bugs@suse.de |simonf.lees@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c2 --- Comment #2 from Tomáš Chvátal <tchvatal@suse.com> --- Yea that is nice, but the provides/obsoletes are there because we will be pruning the synergy from the distro and to ensure users move to the new app. They were not added to state 100% compatibility in this case. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c3 --- Comment #3 from Tomáš Chvátal <tchvatal@suse.com> --- (In reply to Tomáš Chvátal from comment #2)
Yea that is nice, but the provides/obsoletes are there because we will be pruning the synergy from the distro and to ensure users move to the new app. They were not added to state 100% compatibility in this case.
@Simon: we should probably release MU also for Leap 15.1 as the concurent usage of Leap and TW is happening aroundy, opinion? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c4 --- Comment #4 from Martin Wilck <martin.wilck@suse.com> --- Why prune synergy just now? Who decided that, and why? I agree that moving to barrier is generally a good idea for most people who need KVM and nothing more. But synergy 1.9.1 is GPL, is under active development, and has no big issues AFAIK, I see no reason to rush its removal. Not to mention that this move hasn't been announced on opensuse-factory or anywhere else AFAICT (I probably would have missed it anyway if you did, but at least then I couldn't complain). synergy is used a lot in mixed environments. There may be paying Symless customers who'd be unable to use the software they bought with openSUSE clients, because synergy and barrier are incompatible. Even for those users who don't have such incompatibility issues, a smoother upgrade path would be desirable. I spent considerable time today trying to figure out why my KVM wasn't working any more. In a larger installment, doing this would cause a major disruption for admins and a lot of frustration, even if it was possible to migrate every system. For example, barrier could use an existing "/etc/synergy.conf" by default if available, by copying it to "/etc/barrier.conf" during update (luckily, these configuration files seem to be compatible). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c5 --- Comment #5 from Martin Wilck <martin.wilck@suse.com> --- (In reply to Tomáš Chvátal from comment #3)
@Simon: we should probably release MU also for Leap 15.1 as the concurent usage of Leap and TW is happening aroundy, opinion?
This is not only about openSUSE. We have to consider mixed environments. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c6 --- Comment #6 from Simon Lees <simonf.lees@suse.com> --- Hi All, To start with it wasn't my intention to start migrating tumbleweed users from synergy to barrier yet, (My fault for not paying close enough attention to the new spec). My plan was to first do some testing (so far working really well, but today i'll aim to get a windows machine involved). But given i'm happy with the results so far i'm pretty much ready to move to the next stage which is as follows. I intend to only include barrier in Leap 15.2, and drop synergy from tumbleweed at the end of the 15.1 lifecycle. Synergy upstream no longer care about the 1.X branch and have long moved onto 2.0 which is an electron based app much of which is not open sourced. I will mention that someone can take over the package if they really really want to but i'd still prefer to migrate most users around 15.2 release time. Given that some users will have a combination of 15.1, 15.2 and tumbleweed adding the package via maintenance update does make sense so i'll do that as well. As for migrating configs, generally because synergy is run / configured by users the config files end up in there home directory which makes migration pretty much impossible from a packaging level. But there is a first run wizard and it is written in Qt which I know well so it wouldn't be a huge amount of effort to write another dialog page that checks for synergy configs and attempts to migrate them. I'll probably just need to find a day or to to implement and test it. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com