> Now apart from these changes as a whole I am not so happy about this
> shorewallrc.vendor approach you have made hard coded destinations and
> this does not fit to the previously discussed rpmmacros approach.
>
I doubt the shorewallrc.vendor would be needed if my suggestion of
adopting "%configure" (which lists most, if not all of the
distro-specific directories) is adopted - shorewallrc.%{_vendor} won't
be needed then at all.
> I do not like the idea of installing the following under
> /usr/share/shorewall they belong to %perl_vendorlib as they are modules
>
>
> Shorewall/Accounting.pm
> Shorewall/Chains.pm
> Shorewall/Compiler.pm
> Shorewall/Config.pm
> Shorewall/IPAddrs.pm
> Shorewall/Misc.pm
> Shorewall/Nat.pm
> Shorewall/Proc.pm
> Shorewall/Providers.pm
> Shorewall/Proxyarp.pm
> Shorewall/Raw.pm
> Shorewall/Rules.pm
> Shorewall/Tc.pm
> Shorewall/Tunnels.pm
> Shorewall/Zones.pm
>
I agree with that too.
> I would rather go back to the 4.5.1 install and packaging routine which
> used the rpmmacros
>
The "old" (busted) installation method is fraud as it has many of the
directories used hard-coded, making it impossible to install any
shorewall products in places where there is no package management system
available (routers, smartphones, embedded devices in general comes to
mind).
By having the whole product packaged in a tar archive and using a simple
install script to install and then uninstall/upgrade is the way to go,
but then I would need to be able to specify/redefine the directories
used for that installation, hence the need of an additional file
(whether this is shorewall-pkg.config or .shorewallrc is a matter of
debate) to store these.
------------------------------------------------------------------------------
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
