https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-281 Lustre <p>For many types of systems software packages can be store in non standard locations. For example on crays the lustre packages are stored in /opt/cray based on the lustre versions. This allows one to use specific lustre version without rebuilding images for the servers. Normally you do just a ./configure --prefix="special path" and it works. While doing this I discovered several problems. Several parts of the lustre package are hard coded to where they are installed. Also the rpms generated ingnore the prefix you provide. My hope is this ticket will resolve these issues.</p> Lustre servers and cray and non cray lustre clients LU-281

autoconf improvements and rpm generation fixes

Improvement Minor Resolved Duplicate Brian Murrell James A Simmons Thu, 5 May 2011 08:58:37 +0000 Wed, 11 Apr 2012 10:51:07 +0000 Wed, 11 Apr 2012 10:51:07 +0000 Lustre 2.1.0 0 3 <p>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</p> <ol> <li>we need to eval "configure" because $CONFIGURE_ARGS could have a quoted</li> <li>string in it which we don't want word splitted by the shell<br/> %define eval_configure %(echo '%configure' | sed -e 's#\./configure#eval ./configure#')</li> </ol> <p>%eval_configure \<br/> %{?kdir: --with-linux=%kdir} %{?kobjdir: --with-linux-obj=%kobjdir} \<br/> $CONFIGURE_ARGS<br/> make -j $RPM_BUILD_NCPUS -s</p> <p>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.</p> <p>Brian</p> <p>Could you please comment on this?</p> <p>Thanks</p> <p>Peter</p> <blockquote> <p>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.</p></blockquote> <p>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.</p> <p>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:</p> <blockquote> <p>./configure --prefix="special path"</p></blockquote> <p>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.</p> <p>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 </p> <p>%attr(-, root, root) %{_libdir}/liblustreapi.a</p> <p>which is proper but you also have </p> <p>%attr(-, root, root) /usr/bin/*</p> <p>which is hard coded.</p> <p>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.</p> <blockquote> <p>Sorry I have been busy with other bugs.</p></blockquote> <p>Heh. I understand completely.</p> <blockquote> <p>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.</p></blockquote> <p>So you want to override the vendor's defaults for those?</p> <blockquote> <p>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.</p></blockquote> <p>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.</p> <p>Most if not all macros that you can pass in with --define should have reasonable default such that you are not <b>required</b> 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.</p> <p>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.</p> <p>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.</p> <p>I am starting to gather ideas for how the spec file should work over in <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a>.</p> <p>Are you suggesting that I close this bug and just use <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a></p> <p>As a side not I was moving over to passing in all the configure args in the autoMakefile.toplevel.<br/> 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 :-/</p> <p>I am not necessarily suggesting that you close this bug. I just wanted you to be aware of <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a> so we could start talking and avoid stepping on each other's toes.</p> <p>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.</p> <p>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 <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> The patch for this bug coudl be the start of the work for <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a>.</p> <p>Peter you can close this bug. I'm going to move this work over to <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a>.</p> <p>ok thanks James</p> Development Rank 1|hzw01r: Rank (Obsolete) 10087