> This is the current state of the changes to these files (from the 4.5.1
> release notes):
>
> 1) Previously, the install scripts included in the Shorewall packages
> were very restrictive. They could either be run to install directly
> onto the system in a distribution-dependent way, or they could
> install into a directory in a distribution-independent way. This
> limited their usefullness to packagers.
>
> Beginning with this release, the install scripts handle the install
> system and the target system independently. When running an
> installer, the following environmental variables can be set:
>
> a) HOST - Describes the system where the installer is
> running. Accepted values are:
>
> CYGWIN - Cygwin running under a Microsoft OS
> MAC - OS X
> DEBIAN - Debian
> REDHAT - Fedora,RHEL,Centos,Foobar,etc.
> SLACKWARE - Slackware
> ARCHLINUX - Arch Linux
> LINUX - Generic Linux
>
> If HOST is not set, then the installer uses its existing
> algorithm for detecting the current OS and distribution.
>
> b) TARGET - Describes the system where the installed package
> will run.
>
> - For Shorewall and Shorewall6, the possible values are
> the same as for HOST.
>
> - If TARGET is not set, the value of HOST (through setting or
> detection) is used.
>
> - For Shorewall-lite and Shorewall6-lite, the possible choices
> are DEBIAN, REDHAT, SUSE, SLACKWARE, ARCHLINUX and
> LINUX.
>
> - For Shorewall-init, the possible choices are DEBIAN,
> REDHAT, and SUSE.
>
> c) INITDIR - Gives the absolute path name of the directory
> containing the init scripts.
>
> The choice of HOST and TARGET follow the naming of similar macros
> in rpm.
>
> As part of these changes, LIBEXEC and PERLLIB must now hold an
> absolute pathname. So, for example, if you have been using
>
> LIBEXEC=libexec
>
> you will need to change to
>
> LIBEXEC=/usr/libexec
>
All very good - it was long overdue I'd say!
> 2) The .spec files included with each package have undergone
> considerable revision.
>
> When running the package's ./install.sh script:
>
> a) The setting for LIBEXEC is taken from the standard '_libexecdir'
> rpm macro.
>
I am not sure (I am away and cannot check this at present), but I think
the "standard" rpm deployment has this already defined, along with a
host of other such directories, like %{_bindir}, %{_libdir} etc - it is
worth considering instead of introducing yet another variable.
> b) The setting for PERLLIB is taken from the standard
> 'perl_sitelib' rpm macro.
>
Again, I think this could also be determined/is already defined by rpm
itself - I'd be able to give you more definite answer later this evening
when I get home - I use the perl library directory macro in one of my
SELinux policy .spec files, so I need to look whether this is already
defined within rpm.
> c) The setting for INITDIR is taken from the new
> 'shorewall_initdir' rpm macro.
>
> d) The setting for TARGET is taken from the new
> 'shorewall_target' rpm macro.
>
I take it the usage is either shorewall_initdir or INITDIR, but not both
(if not so, which one does take precedence?), right?
> In all cases, the %file specifications now use the above rpm
> macros where appropriate
>
> The rpms included with Shorewall are build with these
> definitions in $HOME/.rpmmacros:
>
> %perl_sitelib /usr/share/shorewall
> %shorewall_initdir /etc/init.d
> %shorewall_target SUSE
>
> From /usr/lib/rpm/macros comes this effective setting:
>
> %_libexecdir /usr/libexec
>
> The setting of %perl_sitelib is chosen for portability, since there
> seems to be no common location for site-specific Perl modules among
> the rpm-based distributions.
>
Would you be able to clarify the default directory layout of shorewall -
what component should be where (in which directory)? It would help me
better understand the reasons behind the chosen layout and your choice
of directories.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
