Details
-
Technical task
-
Resolution: Not a Bug
-
Minor
-
None
-
None
-
None
-
9223372036854775807
Description
LU-7228 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.
But lustre-client was really never intended for long term standard usage, and we should avoid exposing it to users at all cost.
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".
Some date far in the future we can promote lustre-devel to being its own proper package.
I think that approach probably sets us on a more reasonable long term path.
Attachments
Issue Links
Activity
right, so we could discuss this removal of "Provides: lustre-client" once we have server and client code in different packages. (LU-3957)
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.
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.
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.
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.
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?
I agree Andreas. lustre-devel != lustre-client. And if there is a devel package, I think that should be lustre-client-devel.
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.
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.
We've also discussed in LU-3957 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?
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.
I concede the point. I'll retract this ticket.