Problem: SuSEfirewall2-3.6.378-2.1.noarch conflicts with firewalld provided by firewalld-0.5.1-1.1.noarch
Solution 1: Following actions will be done:
deinstallation of firewalld-0.5.1-1.1.noarch
deinstallation of firewalld-lang-0.5.1-1.1.noarch
Solution 2: deinstallation of SuSEfirewall2-3.6.378-1.1.noarch
Solution 3: keep obsolete SuSEfirewall2-3.6.378-1.1.noarch
The following product is going to be upgraded:
openSUSE Tumbleweed 20180311-0 -> 20180312-0
There are some strnage things going on with the firewall in TW. I don’t believe this is all clear in the open what’s going on here. You can’t have both firewalls running.
For example firewalld can’t be configured from CLI-YaST. Take care to allow all necessary services in firewalld. Otherwise you might end up locked-out (if machine managed headless, had that yesterday…)
Argument about what exactly? I’ll let you worry about that on the ML.
IMO such conflicts shouldn’t present to the user at “zypper dup” time, that is the bug. Whatever results hopefully will be resolved before Leap 15’s final release. At least there is a bug report now to focus any arguments or discussions.
Well “run in parallel” may not be achievable, but parallel availability - yes, at least as mutually exclusive services.
My understanding is that both could be installed, but only one of them could be allowed to run.
Apparently someone decided that this conflict could be avoided by creating a package conflict (so that only one could be installed). And there seems to be a disagreement as to whether that was an appropriate way to solve the problem.
This is what I gather from reading the bug report and the mailing list messages.
Personally, I’m not too much concerned. Since “firewalld” seems to be the proposed future, I just go with that when there’s a conflict.
In the ML thread I referenced, there is this: “The conversion utility requires both installed… Sounds like a catch22?” (from end of Peter Suetterlin post). A good reason for a bug report, I thought on reading it and what followed. I see no disagreement in that thread. On seeing only a couple of early posts there, I decided to postpone the update. Otherwise I would have chosen to keep the old firewall going, pending a clearer understanding of the replacement in my case. Whether Solution 2 or 3 goes to personal choice, available info, and circumstances.
Apparently someone decided that this conflict could be avoided by creating a package conflict (so that only one could be installed). And there seems to be a disagreement as to whether that was an appropriate way to solve the problem.
The maintainer decided to create the package conflict, but did apologize later in that ML thread. I guess he was motivated by damage limitation, and I suspect issues lie with the conversion utility.
firewalld is a very nice piece of software, much better than susefirewall2. For basic users i would not recommend using the conversion script. it appears to simply copy over the port settings, which for a service like kde connect can be dozens. If you set up firewalld from scratch you can allocate, monitor and control as a named service. A good tutorial to get up to speed is the following.