Hi, gustavo: thanks for bringing this up. Installing multiple firewall tools could indeed cause big trouble for those not experienced with such tools.
I like Erich's idea: a "Conflicts:" would be a too blunt tool. Once a consensus has formed I'd be very happy to adjust the uruk package. I'm Cc-ing https://lists.debian.org/debian-firewall/ and moving original list of recipients to Bcc; I feel this discussion could use a more public place. Bye, Joost On Wed, Jul 24, 2019 at 11:11:20PM +0200, Erich Schubert wrote: > Hi, > > 1. People may want to try out different tools, and many tools can be > disabled in one way or another; so being installed at the same time does not > imply they are being used at the same time and interfering. A similar issue > arises for example with display managers. Conficts are the wrong way of > handling this, because you prohibit users from trying out different tools > easily. > > In particular, firewall tools usually need to be configured and will not > automatically run (as this could lock you out in the worst case). > > 2. They are not necessarily incompatible. > > pyroman generates iptables-restore scripts, because this is much faster to > load than repeated invocations of iptables. > > But that means it actually makes sense to combine this in particular with > iptables-persistent. > > And I even have a system where I have iptables-persistent installed along > with pyroman. > > So please do NOT add "conflicts". > > To quote Debian policy: > > > Neither Breaks nor Conflicts should be used unless two packages cannot be > installed at the same time or installing them both causes one of them to be > broken or unusable. Having similar functionality or performing the same > tasks as another package is not sufficient reason to declare Breaks or > Conflicts with that package. > > At maximum, the solution should be a debconf question asking the user which > firewall tool to use if multiple are installed, as done for example with > display managers such as gdm, kdm, lightdm. But since these tools usually > need to be configured anyway to be useful, I don't see much benefit of doing > this. > > What I can imagine is, however, introducing some indicator that allows one > tool to detect that another tool is being used at the same time. For > example, all tools could generate some unused iptable "firewall-tool-name-X" > and check the presence of such tables as an indicator for possible > misconfiguration to warn the user. > > Regards, > Erich > > On 22.07.19 21:57, gustavo panizzo wrote: > > > >Hello, > > > >This email is regarding an iptables manager on which you are listed as > >maintainer [1]. > > > >I maintain iptables-persistent, a script to setup iptables rules at > >boot; all of you maintain [1] a firewall manager. > > > >I was working on #926927 when I realize that users can install our > >packages at the same time, which will surely cause them problems. > > > >I think that besides implementing something along the proposed solution > >to #926927 we should implement package level Conflicts [2] between our > >packages. Maybe to make it easier and extendable we should all Provide and > >Conflict > >with a meta-package (firewall-manager?) > > > >what do you guys think? > > > > > > > >[1] - > >Package: uruk > >Maintainer: Joost van Baal-Ilić <[email protected]> > >Package: ufw > >Maintainer: Jamie Strandboge <[email protected]> > >Package: uif > >Maintainer: Mike Gabriel <[email protected]> > >Package: sidedoor > >Maintainer: Dara Adib <[email protected]> > >Package: shorewall > >Maintainer: Roberto C. Sanchez <[email protected]> > >Package: pyroman > >Maintainer: Erich Schubert <[email protected]> > >Package: ipkungfu > >Maintainer: Luis Uribe <[email protected]> > >Package: arno-iptables-firewall > >Maintainer: Debian Security Tools <[email protected]> > >Package: ferm > >Maintainer: Alexander Wirt <[email protected]> > >Package: firehol > >Maintainer: Jerome Benoit <[email protected]> > >Package: firewalld > >Maintainer: Utopia Maintenance Team > ><[email protected]> > > > >let me know if I missed anybody or any package. > > > >[2] - https://www.debian.org/doc/debian-policy/ch-relationships.html > >
