[LU-3422] Lustre Client 2.3 build produces incorrect binary rpm file names

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.3.0
• Type: Improvement
• Priority: Minor
• Reporter: Young Jong Pao
• Assignee: Minh Diep
• Resolution: Won't Fix

Environment

CentOS 6.3 - kernel-2.6.32-279.el6.x86_64

Description

Building the binary RPM from the source produced the incorrect RPM names.

http://downloads.whamcloud.com/public/lustre/lustre-2.3.0/el6/client/RPMS/x86_64/

lustre-client-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64.rpm
lustre-client-debuginfo-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64.rpm
lustre-client-modules-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64.rpm
lustre-client-source-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64.rpm
lustre-client-tests-2.3.0-2.6.32_279.5.1.el6.x86_64.x86_64.rpm

With centOS 6.3, kernel-2.6.32-279.el6.x86_64, my build ended up with the same RPMs names (i.e. x86_64.x86_64).

There is nothing wrong with the macros or the SPEC file. The fact that the kernel release already has "x86_64" in it (2.6.32-279.el6.x86_64) resulted in RPMs name with duplicated string "x86_64".

Could you update the upstream file, lustre.spec.in, to correct the naming to prevent the confusion now and in the future in case the future kernel release might carry "x86_64"?

Suggest to replace the line:
Release: %

{fullrelease}
with
Release: %(bash -c "echo %{fullrelease}

| sed -e 's/\.x86_64$//' -e 's/\.i[3456]86$//' -e 's/-smp$//' -e 's/-bigsmp$//' -e 's/-ppc64$//' -e 's/-default$//'")

Comments

[Peter Jones]

Minh

Could you please comment?

Thanks

Peter

[Minh Diep]

yes, we are aware of this. I'd like to check with Brian to see if there's any issue.

[Young Jong Pao]

Minh,
I am following up to see whether this naming will be corrected in the future or not, and whether this has caused confusion or issues among vendors/customers.

Thanks.

[Brian Murrell (Inactive)]

Strictly speaking, given our current policy, this duplication of the arch is not a bug and is the intended behaviour (ugly or not). This is because the first x86_64 is actually part of the official kernel version/release string, which is embedded into the release string of the Lustre RPMs.

Should we decide to correct this, I think the situation needs to be examined in more detail and addressed in a more comprehensive manner than just stripping possible strings out of the fullversion macro.

[Young Jong Pao]

Brian,
Thanks for your quick response to the matter. Since it is the intended behaviour I would suggest to close this LU-3422. We'd explain to our customers if confusion persists. Thank you.

Young