Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
3
-
9223372036854775807
Description
This re-adds the lustre-devel package.
Attachments
Issue Links
- is related to
-
LU-9897 Tracking of lustre library improvements.
-
- Open
-
Activity
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
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.
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
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.
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.
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.
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.
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).
Building other tools that want to use Lustre also needs this, such as Robinhood.
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?
Aa true man of the people
Landed for 2.14