>> [USR]
>>
>
> I had it the other way initially; then I tried to modify the rc file to
> install Shorewall in /opt. That's when I added the additional variable
> because it made that process much easier.
>
OK, but give it a meaningful name, like "PREFIX", "EXEC_PREFIX" or
"PROGRAM_PREFIX" (similar to what RPM uses for example). I still can't
understand why do you need it though - it is not directly used anywhere
- it is just a part of another variable, which could be modified as well.
As for "/opt" - this is what my intention is also - to see whether I
could install all shorewall packages in it. That is what I intend to
test next after reviewing the install/uninstall scripts.
>>> LIBEXECDIR (Req'd) -- Directory where product executables are
>>> installed. Normally /usr/share or
>>> /usr/libexec.
>>>
>> Do you actually need this? System executables normally go to /sbin or
>> /usr/sbin.
>>
>
> There has been a lot of discussion about this on the development list.
> Yes, it is needed for executables that Shorewall products run internally.
>
Well, I am subscribed to the shorewall development list and don't
remember such discussion ever taking place. Unless you mean another
development list. In LIBEXECDIR, from what I could gather, you have just
2 files - compiler.pl, and, I think, getparams. Does this warrant a
separate directory? Why not put this together with the other perl stuff?
> Some packages have a file called sysconfig that must be installed in the
> SYSCONFIG directory as ${SYSCONFIG}/$PRODUCT. That is why this variable is
> needed.
>
I have no problems with SYSCONFIG as such - the name of the file you
choose to put in that rc file (sysconfig) is different from the actual
name advertised ($PRODUCT). I think it should be $PRODUCT, not "sysconfig".
>> #
>> # Load packager's settings if any
>> #
>> [ -f ../shorewall-pkg.config ] && . ../shorewall-pkg.config
>>
>> #![...]
>>
>> if [ -n "${DESTDIR}" -a -f ../shorewall-pkg.config ]; then
>> . ../shorewall-pkg.config || exit 1
>> #!
>> #! So, shorewall-pkg.config is sourced twice, if it exists. Why?
>> #!
>>
Why do you need this?
>> file = ../shorewall-pkg.config
>> elif [ -f ~/.shorewallrc ]; then
>> #!
>>
>
>
>> Why do you reference ~/.shorewallrc and sourcing it if it exists? For
>> what purpose?
>>
>
> Think about people like me that only install from tarballs and install.sh
> (not all of us use packaging systems; especially those of use who develop
> and test Shorewall). Once the first >= 4.5.2 Shorewall-core is installed,
> We don't have to worry about where we have decided to install all of the
> components; we just run the install.sh scripts without any argument.
>
Ah, I see. So, previous settings are used, if available, to install
shorewall products. That needs to change though to reflect the order of
priority, starting from current directory, /etc and so on - as discussed
yesterday.
Also, am I right in thinking that *all* shorewall products need/are
dependent on shorewall-core?
Another query - in all of your install.sh/uninstall.sh you use $PRODUCT.
What are the possible variations on this - so far I know of "Shorewall"
and "Shorewall-lite", along with their "6" counter parts, so that makes
it 4 different "products". Are there any more of those?
Another thing I spotted yesterday was that you have a lot of
inconsistent use of "$PRODUCT" and "shorewall" hard-coded as part of
directory setup in your scripts - I'll look into this further today.
>> It is good that you thought of removing (older) shorewall installations
>> by using absolute paths. On a separate note - I just realised that for
>> some reason I have "/var/lib/shorewallundo_rfc1918_routing" as well as
>> "/var/lib/shorewall/undo_rfc1918_routing" - I am still on 4.5.1.
>>
>
> Those are used by 'restart' and 'stop' processing.
>
This can't be right! I have "/var/lib/shorewallundo_rfc1918_routing"
(note tha absence of "/" between "shorewall" and
"undo_rfc1918_routing"). This file is zero sized. I have no qualms with
"/var/lib/shorewall/undo_rfc1918_routing" - that is perfectly legitimate
and I know what it could be used for, but the existence of the former is
a mistake, I think.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
