On Tue, Oct 09, 2007 at 12:16:21AM +0100, Jonathan Underwood wrote:
> While working on the packaging of shorewall 4.0.4 for Fedora[1], a few
> issues have arisen related to the shorewall-perl compiler, and the
> file Ports.pm, the file which is essentially a hash of
> /etc/{services,protocols}.
>
> Firstly, since this is an application file representing local machine
> state, I think it should be kept under /var/lib/shorewall-perl rather
> than /usr/share/shorewall-perl/Shorewall. This is particularly
> pertinent for machines which have /usr mounted read only.
>
> Secondly, the generation of Ports.pm presents a few challenges from a
> packaging perspective. The simple approach is to generate it at
> package build time against the default /etc/{services,protocols}.
> However this is only useful if the user has made no local
> modifications to/etc/{services,protocols}. The user who modifies these
> files may not know to run buildports again. Also, another package may
> (silently) modify /etc/{services,protocols} on installation, again
> causing a problem.
I find myself wondering why buildports.pl exists at all. Tom, did you
have anything in particular in mind? I observe the following on my
(admittedly pretty fast) desktop:
[EMAIL PROTECTED]:~/src/shorewall-perl-4.0.3$ time perl buildports.pl >/dev/null
real 0m0.084s
Given that the relevant files can be loaded and parsed in under .1
seconds (and I would not expect them to be difficult to parse, since
libc does it all the time anyway, in each new process spawned), there
does not appear to be a performance issue here that would prevent
parsing services and protocols every time the shorewall compiler is
invoked. Is there some other reason for doing it this way?
-------------------------------------------------------------------------
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
