On Sun, Oct 07, 2007 at 07:16:58PM +1000, Paul Gear wrote: > >> I think most of the opinions voiced in that thread indicated that the > >> behaviour was very much *not* right for Shorewall users, despite the > >> fact that it might be "right" in the Debian sense. > > > > How many of those users would be willing to sacrifice a well-behaved > > package manager in order to have an alternative to running the > > shorewall command directly? The opinion of a user who doesn't > > understand the system is not automatically valid, and is frequently > > misguided. > > Now you're losing me. Why would having an alternate version of the > Shorewall packages for Shorewall users mean that they are sacrificing a > well-behaved package manager? > > I agree with you that we simply discourage the use of the init script as > a user interface, but if consensus is that '/etc/init.d/shorewall stop' > should be equivalent to 'shorewall stop', i can't see that that would > thereby compromise the whole of the packaging system.
The package system is subtle and quite involved; the rules have been carefully worked out through years of experience with thousands of packages. Meddling with them can create all kinds of strange effects. For example, let's assume you did the following: apt-get install shorewall # ... # (start setting it up) # ... # actually, I wanted the other one... apt-get install shorewall-lite Would you expect the last command to disable your network access? Behind the scenes, apt noted that shorewall-lite conflicts with shorewall, so it scheduled shorewall for removal. As part of the removal process, the shorewall init script was instructed to stop, under the assumption that this would return the system to its pre-shorewall state, ready for installation of shorewall-lite. Unexpected results like this are likely to happen all the time if you have an init script where 'stop' does not undo 'start'. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
