After giving net-firewall/shorewall-4.0 a try this afternoon I ran into some problems with multicast traffic still logged which was based on problems with the SHOREWALL_COMPILER used (shorewall-shell). After chatting with upstream on #shorewall at freenode it seems that the recommended way to install shorewall-4 is with shorewall-perl instead of shorewall-shell. See herefore http://www.shorewall.net/Shorewall-4.html ... Reproducible: Always Steps to Reproduce: 1. emerge =net-firewall/shorewall-4.0 2. 3. Actual Results: =net-firewall/shorewall-4.0 rdepends on =net-firewall/shorewall-common-4.* which pulls in =net-firewall/shorewall-shell-4.* Expected Results: =net-firewall/shorewall-4.0 should just give out an explanation what to do in case of upgrade or new install. upgrade) install =net-firewall/shorewall-shell-4.* (with RDEPEND on =net-firewall/shorewall-common-4.*) new) install =net-firewall/shorewall-perl-4.* (with RDEPEND on =net-firewall/shorewall-common-4.*)
Vieri, please, provide updated ebuild (attach patch).
(In reply to comment #0) > Actual Results: > =net-firewall/shorewall-4.0 rdepends on =net-firewall/shorewall-common-4.* > which pulls in =net-firewall/shorewall-shell-4.* > > Expected Results: > =net-firewall/shorewall-4.0 should just give out an explanation what to do in > case of upgrade or new install. > > upgrade) > install =net-firewall/shorewall-shell-4.* (with RDEPEND on > =net-firewall/shorewall-common-4.*) > > new) > install =net-firewall/shorewall-perl-4.* (with RDEPEND on > =net-firewall/shorewall-common-4.*) well, the ebuild does pull in shorewall-shell automatically and it was originally meant for two reasons: 1) in the early stages of 4.x, shorewall-shell was required even if you wanted perl (or at least that's what seemed to be the case) 2) users upgrading from <4.x would not have any trouble if they wished to continue using the shell. If they required the perl compiler they just needed to emerge shorewall-perl. Anyway, it sounds correct to make the shorewall <4.x user emerge shorewall-common and then require him to emerge manually either shell or perl. It also avoids pulling in shorewall-shell automatically although it doesn't hurt. Will post the diffs asap.
Created attachment 144588 [details, diff] shorewall-4.0.ebuild.diff
Created attachment 144590 [details, diff] shorewall-common-4.0.9.ebuild.diff
Created attachment 144593 [details, diff] shorewall-lite-4.0.9.ebuild.diff
Created attachment 144595 [details, diff] shorewall-perl-4.0.9.ebuild.diff
Created attachment 144597 [details, diff] shorewall-shell-4.0.9.ebuild.diff
Viery, patches seems to be Ok here. But why did you dropped keywords? If there are no reasons for this I commit your patches but leave KEYWORDS as they were...
(In reply to comment #8) > But why did you dropped keywords? I dropped the keywords because I read on the Gentoo web site that a submitted custom ebuild should only have archs for which it has been tested. If that's not how it's supposed to be done then next time I won't drop any keywords. Thanks
(In reply to comment #9) > I dropped the keywords because I read on the Gentoo web site that a submitted > custom ebuild should only have archs for which it has been tested. If that's > not how it's supposed to be done then next time I won't drop any keywords. No-no. That was supposed for new packages only. That was written because users submitted ebuild for packages which possible to compile on x86 only with all archs set :) In case you are doing version bump or update package in some way you should not drop keywords without specific reason :) Well, I'm going to commit in few moments...
(In reply to comment #10) > In case you are doing version bump or update package in some way > you should not drop keywords without specific reason Understood. Thanks for clarifying.
Well and now everything is in CVS, please, check and reopen if something went wrong. BTW, Vieri, also not important bug also you can leave # $Header: as is. CVS is smart enough to overwrite it on commit. Again only for new packages it's worth cleaning that line for all others it's Ok not to spent time on that. Thank you, Stefan for report, and Vieri for the fixes! Enjoy :)
