When it comes to rpm generation I discovered that the configure options actually get lost in the lustre.spec.in file. The offending section is
- we need to eval "configure" because $CONFIGURE_ARGS could have a quoted
- string in it which we don't want word splitted by the shell
%define eval_configure %(echo '%configure' | sed -e 's#\./configure#eval ./configure#')
%eval_configure \
%{?kdir: --with-linux=%kdir} %{?kobjdir: --with-linux-obj=%kobjdir} \
$CONFIGURE_ARGS
make -j $RPM_BUILD_NCPUS -s
I don't know what conditions where you seen this shell splitting problem so I don't know how to fix this problem without breaking what the fix was originally trying to accomplish.
Brian
Could you please comment on this?
Thanks
Peter
I don't know what conditions where you seen this shell splitting problem so I don't know how to fix this problem without breaking what the fix was originally trying to accomplish.
This change was made long enough ago now that I don't recall the specific case, but there most certainly would have been one for me to go through the rigmarole that that code goes through.
Just reading the comment though, I could imagine quite easily where $CONFIGURE_ARGS could have a quoted string in it. Your description even provides a case of a quoted string:
./configure --prefix="special path"
All of that said, passing parameters to the rpm build through subst'd configure arguments is just wrong and should not be further depended on/used. Optional parameters should be provided through rpm macros --defined on the rpmbuild command line.
Using rpmbuild --defined="prefix=/special/path" lustre.spec will not work since the lustre spec file hard codes all the paths. In the spec file you have
%attr(-, root, root) %{_libdir}/liblustreapi.a
which is proper but you also have
%attr(-, root, root) /usr/bin/*
which is hard coded.
Sorry I have been busy with other bugs. Yes I agree the proper approach is to pass the configure variables via the RPMARGS. Right now I have RPMARGS="$$RPMARGS --define '_prefix ${prefix}' --define '_mandir ${mandir}' --define '_datadir ${datadir}' --define '_sysconfdir ${sysconfdir}'"; in the autoMakefile.am.toplevel. In fact I was thing of a creating a for loop that appends a --define for each configure_args. We just have to filter the options using a string out. Just running this idea pass you first.
Sorry I have been busy with other bugs.
Heh. I understand completely.
Yes I agree the proper approach is to pass the configure variables via the RPMARGS. Right now I have RPMARGS="$$RPMARGS --define '_prefix ${prefix}' --define '_mandir ${mandir}' --define '_datadir ${datadir}' --define '_sysconfdir ${sysconfdir}'"; in the autoMakefile.am.toplevel.
So you want to override the vendor's defaults for those?
In fact I was thing of a creating a for loop that appends a --define for each configure_args. We just have to filter the options using a string out. Just running this idea pass you first.
Yes, I like the sounds of this idea. Of course you have to make a corresponding change to the lustre spec file to receive the --defined arguments. But this is how spec files should work. We just happen to have a lot of arguments we can give configure.
Most if not all macros that you can pass in with --define should have reasonable default such that you are not required to set any with rpmbuild. Most in fact would probably already have reasonable defaults built into configure so anything empty should just be unspecified to configure and that would be your reasonable default. No point in duplicating configures built in reasonable defaults to the rpm spec also.
I just pushed a patch that does it the right way. It's mostly complete except for the /etc, man and doc directory don't respect the prefix but its a good start.
I am not a fan of looping over %configure_args in the spec file. I am already not fond of the level of dependency that the spec file code has on the contents of %configure_args. The code is really pretty fragile, and makes using lustre src rpms extremely difficult.
I am starting to gather ideas for how the spec file should work over in LU-1199.
Are you suggesting that I close this bug and just use LU-1199
As a side not I was moving over to passing in all the configure args in the autoMakefile.toplevel.
So in theory see yes the spec file can be configure agnostic. Just didn't rock the boat with to many changes in the hopes of it going into main line very soon. Now that the window is closed I think we can move in a more proper direction. BTW that is lot of options to handle :-/
I am not necessarily suggesting that you close this bug. I just wanted you to be aware of LU-1199 so we could start talking and avoid stepping on each other's toes.
I am not suggesting that the spec file learn all of lustre's configure options. The spec file only needs to know about the options that require the spec file to change its behavior. All other configure options can still be specified through %configure_args, and the spec file will simply pass those options through to configure without inspecting or changing them.
The reason I asked about closing this bug is that the approach taken with the spec files you posted links to is a much better than what I'm doing. You specs files are nice and clean 
The patch for this bug coudl be the start of the work for LU-1199.
Peter you can close this bug. I'm going to move this work over to LU-1199.
ok thanks James