http://bugzilla.suse.com/show_bug.cgi?id=1169661 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c1 Martin Wilck changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tchvatal@suse.com --- Comment #1 from Martin Wilck --- 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 http://bugzilla.suse.com/show_bug.cgi?id=1169661#c2 --- Comment #2 from Tomáš Chvátal --- 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#c4 --- Comment #4 from Martin Wilck --- 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#c6 --- Comment #6 from Simon Lees --- 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.