[LU-8230] Remove "Provides: lustre-client"

• Type: Technical task
• Resolution: Not a Bug
• Priority: Minor
• Assignee: Minh Diep
• Reporter: Christopher Morrone (Inactive)

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.

Issue Links

• is related to: LU-7228 lustre rpm should provide lustre-client
• is related to: LU-7357 Add layout lock for striped directories.

Comments

[Christopher Morrone (Inactive)]

I concede the point. I'll retract this ticket.

[Minh Diep]

right, so we could discuss this removal of "Provides: lustre-client" once we have server and client code in different packages. (LU-3957)

[Christopher Morrone (Inactive)]

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.

[Minh Diep]

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.

[Frank Zago (Inactive)]

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.

[Christopher Morrone (Inactive)]

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?

[Frank Zago (Inactive)]

I agree Andreas. lustre-devel != lustre-client. And if there is a devel package, I think that should be lustre-client-devel.