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_prefix=
PERLLIB=/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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
