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-8230 Lustre <p><a href="https://jira.whamcloud.com/browse/LU-7228" title="lustre rpm should provide lustre-client" class="issue-link" data-issue-key="LU-7228"><del>LU-7228</del></a> introduced a new "Provides: lustre-client" line to the lustre.spec file. I see what was trying to be accomplished here, to give a single name upon which other packages can add to their BuildRequires or Requires fields.</p> <p>But lustre-client was really never intended for long term standard usage, and we should avoid exposing it to users at all cost.</p> <p>I would assume that what another package really depends upon is the lustre libraries and headers. These are the things that typically appear in at -devel package. Eventually, it would be very nice if Lustre offered a lustre-devel package. So perhaps in the mean time, we can remove the "Provides: lustre-client" and replace it, where appropriate, with "Provides: lustre-devel".</p> <p>Some date far in the future we can promote lustre-devel to being its own proper package.</p> <p>I think that approach probably sets us on a more reasonable long term path.</p> LU-8230

Remove "Provides: lustre-client"

Technical task LU-3953 Minor Closed Not a Bug Minh Diep Christopher Morrone Wed, 1 Jun 2016 23:42:59 +0000 Wed, 29 Jun 2016 21:02:30 +0000 Wed, 29 Jun 2016 21:02:29 +0000 0 7 <p>Chris, it isn't clear to me that "Provides: lustre-devel" is the same as "Provides: lustre-client". The former (IMHO) is about being able to compile new applications that access llapi*.h and .a files, while the latter is about providing the client filesystem functionality (i.e. the ability to "mount -t lustre" and access the filesystem). It seems to me that there is justification for both, so that "lustre-devel" could be split into a separate package at some point in the future.</p> <p>I've added Frank and James to this ticket, since they were the ones that added the "Provides: lustre-client" line and should be aware of any changes being made here.</p> <p>We've also discussed in <a href="https://jira.whamcloud.com/browse/LU-3957" title="Create separate server and client binary rpms from one build" class="issue-link" data-issue-key="LU-3957">LU-3957</a> separating "lustre" into "lustre-client" and "lustre-server" (and possibly "lustre-common" for the shared modules?), so I don't agree that "lustre-client" is something that should be considered a temporary workaround. However, it might be that those would only be "lustre-client-modules" and "lustre-server-modules" and we have only "lustre" with all the tools, or "lustre-utils" and "lustre" is just a meta-package to get all the required sub-packages?</p> <p>On a related note, I saw that the .spec still Provides and Obsoletes lustre-lite, lustre-lite-utils, lustre-ldap, and nfs-utils-lustre which are very old (i.e. added in 1.6 to handle packaging changes from 1.4) and could definitely be removed.</p> <p>I agree Andreas. lustre-devel != lustre-client. And if there is a devel package, I think that should be lustre-client-devel.</p> <p>That is true, we may some day correctly generate separate client and server packages from one build. I was thinking the current lustre-client- prefix method with a second redundant build that is total hackery.</p> <p>What was it that the applications actually needed that inspired this Provides in the first place? Was it an application that uses the lustre libraries as I was assuming, or an application that uses lustre command line tools on the client?</p> <p>It was for robinhood that uses both the lustre headers to compile, and the lustre library to run. So it has both a BuildRequires and a Requires directive, for lustre-client.</p> <p>isn't it that today lustre includes client codes where we can mount lustre on a server? so IMHO lustre provides lustre-client is fair.</p> <p>No, the inclusion of the client code is not for the purpose of using clients on server nodes. We just don't package things well yet. At LLNL we just use the stock server-full "lustre" package on almost all node types.</p> <p>right, so we could discuss this removal of "Provides: lustre-client" once we have server and client code in different packages. (<a href="https://jira.whamcloud.com/browse/LU-3957" title="Create separate server and client binary rpms from one build" class="issue-link" data-issue-key="LU-3957">LU-3957</a>)</p> <p>I concede the point. I'll retract this ticket.</p> Related LU-7228 LU-7357 Development End date Fri, 3 Jun 2016 23:42:59 +0000 Rank 1|hzydf3: Rank (Obsolete) 9223372036854775807 Start date Wed, 1 Jun 2016 23:42:59 +0000