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: