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-2229 Lustre <p>When configure for lustre runs it decides the availability of spl/zfs by looking at the host node rather than looking at the build environment.</p> <p>This means that the build node has to have spl/zfs installed even though the actually building of lustre-zfs uses the build environment which has a spl/zfs development environment available.</p> <p>I don't think this make sense, it should not be a requirement for the build host to have every feature installed that the target build is going to contain.</p> <p>This has caused problems here; TT-391; when our build nodes where upgraded.</p> LU-2229

Lustre configure requires zfs/spl on the host node rather than as part of the build environment.

Bug Major Resolved Low Priority Brian Behlendorf Chris Gearing Wed, 15 Feb 2012 08:55:26 +0000 Thu, 9 Jan 2020 07:09:27 +0000 Thu, 9 Jan 2020 07:09:27 +0000 0 4 <p>The proper way to achieve this is to have lbuild build zfs/spl and then use rpm2cpio to unpack the -devel packages and then point configure at them such as is done for the kernel and ofed, as two examples. This is how the original code I wrote for lbuild to do zfs/spl building did it.</p> <p>I recall there is a patch around for doing this zfs/spl build. Is it still undergoing review or has it landed somewhere?</p> <p>The following two patches were merged in to the spl/zfs code. They should allow for installation of the devel packages in to arbitrary buildroots. Although I'd argue this could have been handled using a standard build tool such as mock.</p> <p><a href="https://github.com/zfsonlinux/spl/commit/485b471eb29cfa3a6dbac7de8fda5e020068044a" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/zfsonlinux/spl/commit/485b471eb29cfa3a6dbac7de8fda5e020068044a</a><br/> <a href="https://github.com/zfsonlinux/zfs/commit/389cf730cedd42dd1ef653e9358635c114e458d5" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/zfsonlinux/zfs/commit/389cf730cedd42dd1ef653e9358635c114e458d5</a></p> <blockquote><p>use rpm2cpio to unpack the -devel packages</p></blockquote> <p>I could not really disagree more with this approach. This is a dirty hack to avoid proper rpm building procedures, and should not be encouraged.</p> <blockquote> <p>I could not really disagree more with this approach. This is a dirty hack to avoid proper rpm building procedures, and should not be encouraged.</p></blockquote> <p>I suppose this is another jab at the lack of the use of something like mock in the Intel build farm. In an ideal world, yes, we would (at least investigate) completely overhaul(ing) the build farm to use something like mock (TEI-532) for rpm building. But that's a project which, AFAIK, has not been scoped and prioritized.</p> <p>So given that, we have to work within the boundaries of what is possible to fix this problem today. That is the context in which my suggestion of unpacking the -devel rpm should be taken. This is no different than how any of the other -devel rpms are utilized by configure so this is not a new "dirty hack" but just another instance of a series of existing hacks to be able to build lustre in a "mock-less" build environment without having to be root to install and remove rpms during the build.</p> <p>Does <a href="https://jira.whamcloud.com/browse/LU-3497" title="Lustre build system hardcoded to using ZFS development headers in /usr/include only. " class="issue-link" data-issue-key="LU-3497"><del>LU-3497</del></a> address your problems Murrell?</p> <p>Close old bug</p> Duplicate LU-1103 Development Rank 1|hzuwan: Rank (Obsolete) 2893 Severity