Parinay Kondekar (parinay.kondekar@seagate.com) uploaded a new patch: https://review.whamcloud.com/25997
Subject: LU-9215 build: Re-add the lustre-devel package.
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9022560c5978768aada71bec251db751837f32c3
Hi parinay,
Could you elaborate the reason we want devel packages? is there anything you are doing that can't be done with existing packages?
Building other tools that want to use Lustre also needs this, such as Robinhood.
Brian, I agree that based on the name "lustre-devel" one would assume this would be used by externally-built packages, but if you look at the patch it includes every header from the Lustre source tree (including kernel headers). I would instead expect that lustre-devel would include the lustre/include/lustre directory headers, and the liblustreapi.a library (the liblustreapi.so library should always be installed).
Can we reconsider this ticket ?
We have a use-case where such a package would be useful: we build an external LND, which needs to be rebuilt with each new lustre release. Having the headers (mainly lustre/include libcfs/include and lnet/include), the config.h and the Module.symvers file for a given build in a package would help streamlining the build process.
Would a revised patch that provides such a package with these files (filtering out the kernel headers) be acceptable ?
About the liblustreapi.a, as it is already part of the main lustre rpm, I guess it does not really need to be provided by the -devel package.
spiechurski, I'm not against having a lustre-devel package per-se, but I am against including every header into that package. My preference would be to include header files into that package on an as-needed basis to build the required modules, rather than including everything. That avoids adding dependence on internal implementation details that are not really forming a stable API, and also makes it easier to see which interfaces are actually being used by external modules.
On the other hand, is there a reason that the ptl4lnd is not submitted into the master branch? That would simplify keeping it updated for newer Lustre releases, since you will have at least some of the ptl4lnd updates as part of the ongoing development activities by other parties, even if the LND is itself not always being tested for each patch. Having a small test system at Atos that is fetching any patches from Gerrit that affect LNet and running a brief test (e.g. lnet-selftest with NETTYPE=ptl4) would go a long way to ensuring that this LND does not break.
That is not how devel rpms work. They normally contain only static libraries and user land headers. Your ptl4lnd driver is a kernel driver so its going to always be dependent on the lustre kernel code 
Their is no guarantee that the internal kernel apis will remain stable. In fact more changes to the LNet core are in the pipe line.
I don't think there is any question about the kernel or Lustre APIs being kept stable,, but that doesn't prevent modules from having conditional compilation as we already do with Lustre today.
I don't object in principle to our-of-tree modules being built, but agree that "lustre-devel" is maybe not a good package name unless it also includes both the in-kernel and userspace development headers.
James Simmons (jsimmons@infradead.org) uploaded a new patch: https://review.whamcloud.com/40728
Subject: LU-9215 build: Re-add the lustre-devel package
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1d71647c5ce75d7d7dbd464e218764b7314b7811
By popular demand I added back lustre-devel for user land handling. As for what people are requesting that is kmod-lustre-devel rpm that you want.
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/40728/
Subject: LU-9215 build: Re-add the lustre-devel package
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 16af4e5ed634942cf6d8a847832684c5542a956c
Aa true man of the people 
Landed for 2.14
Actually one more patch. People want the ability to build against external LND drivers.
James, that could go under a separate ticket? My understanding is that would be something quite different - building out-of-tree kernel modules, rather than the patch which just landed, which is for userspace tools that need access to the interface/protocol structures and constants and such?
simmonsja, FYI: https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lnet.pc and https://github.com/Cray/lustre/blob/cray-2.12-int/cray-obs/cray-lustre-api-devel.pc
Andreas I can do that. The only reason I brought this up is that people earlier in this ticket asked for it. Also patch https://review.whamcloud.com/#/c/25997 seemed to be heading into that direction instead of handling the user land devel package handling. Cory those *.pc inspired me to develop the patch that just landed