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
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.
b) The setting for PERLLIB is taken from the standard
''perl_sitelib'' rpm macro.
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.
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.
Comments are welcome,
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
> 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/
On 02/22/2012 05:25 AM, Mr Dash Four wrote:>> >> 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._libexecdir *is* defined by RPM.> >> 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.It is already defined within RPM. As I noted, however, the default setting is distribution- and release-dependent so I override the default in $HOME/.rpmmacros.> >> 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?When running rpmbuild, %shorewall_initdir is the only way to specify the directory containing the init scripts. Here is the text that invokes the installer: DESTDIR=$RPM_BUILD_ROOT \ OWNER=`id -n -u` \ GROUP=`id -n -g` \ LIBEXEC=%{_libexecdir} \ PERLLIB=%{perl_sitelib} \ INITDIR=%{shorewall_initdir} \ TARGET=%{shorewall_target} \ ./install.sh Here''s the %attr specification for the init script: %attr(0544,root,root) %{shorewall_initdir}/shorewall> 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.Because the installer has knowledge of the file hierarchy of a number of distributions, ''default'' is distribution-dependent. I think it would be appropriate to document that on the web site; I''ll work on that over the next day or two. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/
> _libexecdir *is* defined by RPM. >What I meant was, is it defined by RPM *without* using your macros (i.e. in the "vanilla" RPM distribution)?> It is already defined within RPM. As I noted, however, the default > setting is distribution- and release-dependent so I override the default > in $HOME/.rpmmacros. >One thing I still cannot understand - if it is defined within RPM (and I mean the *vanilla* RPM, without having your macros installed - I am dead against this, but that is another topic for discussion altogether) why not stick with that definition, why do you have to redefine it?> When running rpmbuild, %shorewall_initdir is the only way to specify the > directory containing the init scripts. Here is the text that invokes the > installer: > > DESTDIR=$RPM_BUILD_ROOT \ > OWNER=`id -n -u` \ > GROUP=`id -n -g` \ > LIBEXEC=%{_libexecdir} \ > PERLLIB=%{perl_sitelib} \ > INITDIR=%{shorewall_initdir} \ > TARGET=%{shorewall_target} \ > ./install.sh > > Here''s the %attr specification for the init script: > > %attr(0544,root,root) %{shorewall_initdir}/shorewall >I disagree on a number of points. Assuming %{_libexecdir} and %{perl_sitelib} are defined by the *vanilla* RPM, then I don''t see why do I have to install a separate macros in $HOME (and "pollute" my build environment unnecessarily) just to make use of two variables which are used just *once* - you may as well place whatever the value of these are in the .spec file. Besides, "shorewall_initdir" could very-well be substituted with its vanilla-rpm-defined counterpart, which for my distribution - Fedora - is %{_initddir}. Also, the above is missing the "BUILD" setting, which I am also pretty confident could be substituted by Fedora automatically. "TARGET" should also be "HOST". Oh, and $RPM_BUILD_ROOT is %{buildroot} and has been like that for a long time. Lastly, I don''t see the meaning of OWNER and GROUP either - if you are going to execute "id -n -X", then you may as well do it from within install.sh - no need to specify it as a separate environment variable cluttering this spec file even further.> Because the installer has knowledge of the file hierarchy of a number of > distributions, ''default'' is distribution-dependent. I think it would be > appropriate to document that on the web site; I''ll work on that over the > next day or two. >Let me know when you are ready. ------------------------------------------------------------------------------ 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/
On 02/22/2012 08:32 AM, Mr Dash Four wrote:> >> _libexecdir *is* defined by RPM. >> > What I meant was, is it defined by RPM *without* using your macros (i.e. > in the "vanilla" RPM distribution)? > >> It is already defined within RPM. As I noted, however, the default >> setting is distribution- and release-dependent so I override the default >> in $HOME/.rpmmacros. >> > One thing I still cannot understand - if it is defined within RPM (and I > mean the *vanilla* RPM, without having your macros installed - I am dead > against this, but that is another topic for discussion altogether) why > not stick with that definition, why do you have to redefine it? > >> When running rpmbuild, %shorewall_initdir is the only way to specify the >> directory containing the init scripts. Here is the text that invokes the >> installer: >> >> DESTDIR=$RPM_BUILD_ROOT \ >> OWNER=`id -n -u` \ >> GROUP=`id -n -g` \ >> LIBEXEC=%{_libexecdir} \ >> PERLLIB=%{perl_sitelib} \ >> INITDIR=%{shorewall_initdir} \ >> TARGET=%{shorewall_target} \ >> ./install.sh >> >> Here''s the %attr specification for the init script: >> >> %attr(0544,root,root) %{shorewall_initdir}/shorewall >> > I disagree on a number of points. > > Assuming %{_libexecdir} and %{perl_sitelib} are defined by the *vanilla* > RPM, then I don''t see why do I have to install a separate macros in > $HOME (and "pollute" my build environment unnecessarily) just to make > use of two variables which are used just *once* - you may as well place > whatever the value of these are in the .spec file. > > Besides, "shorewall_initdir" could very-well be substituted with its > vanilla-rpm-defined counterpart, which for my distribution - Fedora - is > %{_initddir}. > > Also, the above is missing the "BUILD" setting, which I am also pretty > confident could be substituted by Fedora automatically. "TARGET" should > also be "HOST". Oh, and $RPM_BUILD_ROOT is %{buildroot} and has been > like that for a long time. > > Lastly, I don''t see the meaning of OWNER and GROUP either - if you are > going to execute "id -n -X", then you may as well do it from within > install.sh - no need to specify it as a separate environment variable > cluttering this spec file even further.Okay -- I''ve come to this point: %install DESTDIR=%{buildroot} \ LIBEXEC=%{_libexecdir} \ PERLLIB=%{perl_sitelib} \ INITDIR=%{_initddir} \ HOST=%{_vendor} \ ./install.sh%install Note that I''m not setting BUILD. The reason is as follows: teastep@gateway:~$ fgrep vendor /home/teastep/shorewall/redhat-macros # Configurable vendor information, same as Vendor: in a specfile. #%vendor %_vendor redhat %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu} %_build_vendor %{_host_vendor} %_host_vendor pc %_target_vendor %{_host_vendor} %perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch) %perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo $installvendorlib) teastep@gateway:~$ As you can see, both %_build_vendor and %_host_vendor are set to ''pc'' rather than ''redhat'' on a Fedora. Note that on Centos and Foobar, the value is ''unknown'' rather than ''pc''. Contrast that with OpenSuSE: teastep@gateway:~$ fgrep vendor /home/teastep/shorewall/suse-macros # Configurable vendor information, same as Vendor: in a specfile. #%vendor %_vendor suse %_target_platform %{_target_cpu}-%{_vendor}-%{_target_os}%{?_gnu} %_build_vendor %{_host_vendor} %_host_vendor suse %_target_vendor %{_host_vendor} %perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch) %perl_vendorlib %(eval "`%{__perl} -V:installvendorlib`"; echo $installvendorlib) teastep@gateway:~$ Here, both _build_vendor and _host_vendor are set to ''suse''. The alternative is this: %install DESTDIR=%{buildroot} \ BUILD=%{_build_vendor} \ LIBEXEC=%{_libexecdir} \ PERLLIB=%{perl_sitelib} \ INITDIR=%{_initddir} \ HOST=%{_host_vendor} \ ./install.sh On Redhat system, this would then be needed in $HOME/.rpmmacros: %_host_vendor redhat No special entries would be needed for SuSE-based systems. I tend to favor this second approach but I''m open to comments. Either way, I''ve had to change the distro names in the .install.sh files to lower case. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/
On Feb 22, 2012, at 2:09 PM, Tom Eastep wrote:> > No special entries would be needed for SuSE-based systems. I tend to > favor this second approach but I''m open to comments. >I''ve thought about this some more and I''m fine either way. There are almost no dependencies on the build system (apple and cygwin are the only ones that require special consideration). -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/
> Okay -- I''ve come to this point: > > %install > DESTDIR=%{buildroot} \ > LIBEXEC=%{_libexecdir} \ > PERLLIB=%{perl_sitelib} \ > INITDIR=%{_initddir} \ > HOST=%{_vendor} \ > ./install.sh%install > >[etc] I''ve got a better idea! I am attaching 4 files (hope they''ll pass through the ML, if not let me know and I''ll attach them privately): "shorewall-configure.patch", "shorewall-spec.patch" - these are applied against the latest shorewall version available for *Fedora* SRPM (4.5.0-RC2). If you don''t have it, or can''t find it, I am attaching the original files as a separate archive called "shorewall-4.5.0-RC2.tar.xz" The "shorewall-configure.patch" patch is the most important as it creates a new file called "configure" in the root BUILD tree (i.e. ~/rpmbuild/BUILD/shorewall-4.5.0). As you can see from the modified spec file, you use the distribution''s own %configure so that all distro-dependent directories are passed as parameters - *automatically* - to that "configure" file. This configure file then scans all these parameters and sets the appropriate values as required - you don''t have to do a thing! There is another little nugget I included for your benefit - forcing the stupid Fedora RPM system to spill out its proper host/target triplet (i.e. "<arch>-redhat-linux-gnu") - as you can see, this is done by the %{_target_platform} RPM macro. The last file I am attaching is an example output from "configure". As you can see from that file, I have attached a commented out screen dump of what I get as environment variables passed automatically from the %configure script line in the modified .spec file when all this is executed - this is just an example for you to see what is going on. The "configure" executable dumps, by default, its configuration parameters on the screen, which, I think, is a must to be shown to the end user, just in case something goes awry! So, the whole process goes like this: %configure is executed in the %prep section, sniffing out the desired distro-specific values, placing them in a separate file called "config" and when the various "install.sh" scripts execute later on, they *source* this file to acquire these values. How you treat these variables in your install.sh scripts is up to you really, but this is how I see it working without messing about with rpm macro scripts and other such nonsense. In case the install.sh is executed "manually" from the command line (i.e. during "normal" build - without the .spec file) then you may modify the logic in your install.sh script to source the "config" file only if it exist, ignoring it otherwise - that should be simple enough for you, even with your bash-scripting skills. ;-) Let me know how you are getting on. ------------------------------------------------------------------------------ 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/
On 02/22/2012 07:19 PM, Mr Dash Four wrote:> >> Okay -- I''ve come to this point:> So, the whole process goes like this: > > %configure is executed in the %prep section, sniffing out the desired > distro-specific values, placing them in a separate file called > "config" and when the various "install.sh" scripts execute later on, > they *source* this file to acquire these values. How you treat these > variables in your install.sh scripts is up to you really, but this is > how I see it working without messing about with rpm macro scripts and > other such nonsense.This seems over-engineered to me. It invokes the configure script like so: configure --host=%{_target_platform} --perl-lib=%{perl_privlib} \ --destdir=%{buildroot} --initdir=%{_initrddir} The configure script then writes out a file: disable_dependency_tracking=disable_dependency_tracking BUILD=x86_64-unknown-linux-gnu sbindir=/usr/sbin sysconfdir=/etc HOST=noarch-redhat-linux-gnu bindir=/usr/bin includedir=/usr/include program_prefixPERLLIB=/usr/share/perl5 mandir=/usr/share/man libdir=/usr/lib64 infodir=/usr/share/info localstatedir=/var datadir=/usr/share exec_prefix=/usrconfigure --host=%{_target_platform} --perl-lib=%{perl_privlib} \ --destdir=%{buildroot} --initdir=%{_initrddir} DESTDIR=/home/mr-4/rpmbuild/BUILDROOT/shorewall-4.5.0-0.2.RC2.fc13.x86_64 INITDIR=/etc/rc.d/init.d libexecdir=/usr/libexec prefix=/usr sharedstatedir=/var/lib Ihe install.sh scripts then source that file. The settings for BUILD and HOST in the generated file are not useful to the current install.sh scripts. So a better invocation of configure would be: configure --host=%{_vendor} --perl-lib=%{perl_privlib} \ --destdir=%{buildroot} --initdir=%{_initrddir} --build=%{_vendor} On the other hand, my approach passes the settings directly to install.sh, while accomplishing the same goal: DESTDIR=%{buildroot} \ LIBEXEC=%{_libexecdir} \ PERLLIB=%{perl_privlib} \ INITDIR=%{_initddir} \ HOST=%{_vendor} \ ./install.sh The BUILD setting really isn''t needed since it is only significant on non-Linux platforms. And HOST=%{_vendor} gives the install.sh scripts everything they need to do the install. So I think that I will leave my .spec files the way they are and let the Shorewall distribution packagers decide if they want to follow your suggestions.> > In case the install.sh is executed "manually" from the command line > (i.e. during "normal" build - without the .spec file) then you may > modify the logic in your install.sh script to source the "config" > file only if it exist, ignoring it otherwise - that should be simple > enough for you, even with your bash-scripting skills. ;-):-) What I will do is add this to the top of each of my init.sh scripts: [ -f ../shorewall-rpm.config ] && . ../shorewall-rpm.config So if packagers wish to take an approach such as you have suggested, the install scripts will accommodate it. Note that I''ve changed the name of the file since I fear that ''config'' is a bit too generic. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/
On 02/23/2012 09:29 AM, Tom Eastep wrote:> > What I will do is add this to the top of each of my init.sh scripts: > > [ -f ../shorewall-rpm.config ] && . ../shorewall-rpm.config > > So if packagers wish to take an approach such as you have suggested, the > install scripts will accommodate it. Note that I''ve changed the name of > the file since I fear that ''config'' is a bit too generic.To make this not quite so rpm-centric, I have implemented it with the filename shorewall-pkg.config rather than shorewall-rpm.config. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ 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/