Support for cross-platform RPM package generation #729
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change introduces proper support for generating RPM packages for the designated target platform. The current version of the "pkg_rpm"-rule exposes an "architecture"-option, which is meant to indicate the package's intended platform. Unfortunately, this option is being incorrectly utilized. It is being used to define the "BuildArch"-option in the RPM spec file. However, as per RPM packaging guide (https://rpm-packaging-guide.github.io/): "'BuildArch' should be used if the package is not architecture dependent. For example, if written entirely in an interpreted programming language, set this to BuildArch: noarch. If not set, the package automatically inherits the Architecture of the machine on which it is built". So, it sounds like it actually has nothing to do with target architecture. It is supposed to represent either architecture of host machine or "noarch". The purpose of this patch is to maintain backward compatibility while provide the solution for the described issue. It preserves the existing "architecture"-attribute of the "pkg_rpm" rule, as it might already be in use by someone. It introduces the "target_architecture"-attribute to the "pkg_rpm" rule, aiming to utilize it as a "arch"-suffix for the package name and to provide it to the "rpmbuild"-utility as the value for the "--target" option.
|
Can we figure the right behavior out in the issue before jumping to code. |
Thank you, Tony, I answered in the issue. |
aiuto
reviewed
Sep 13, 2023
| @@ -462,7 +467,10 @@ def main(argv): | |||
| help='The release of the software being packaged.') | |||
| parser.add_argument( | |||
| '--arch', | |||
| help='The CPU architecture of the software being packaged.') | |||
| help='The CPU architecture of the machine on which it is built. ' | |||
| 'If the package is not architecture dependent, set this to "noarch".') | |||
There was a problem hiding this comment.
Doesn't this comment apply to targert_arch?
| @@ -791,21 +794,30 @@ pkg_rpm = rule( | |||
| # funny if it's not provided. The contents of the RPM are believed to | |||
| # be set as expected, though. | |||
| "architecture": attr.string( | |||
| doc = """Package architecture. | |||
| doc = """Host architecture. | |||
|
|
|||
| This currently sets the `BuildArch` tag, which influences the output | |||
There was a problem hiding this comment.
Let's drop "currently" in these
| @@ -791,21 +794,30 @@ pkg_rpm = rule( | |||
| # funny if it's not provided. The contents of the RPM are believed to | |||
| # be set as expected, though. | |||
| "architecture": attr.string( | |||
| doc = """Package architecture. | |||
| doc = """Host architecture. | |||
|
|
|||
| This currently sets the `BuildArch` tag, which influences the output | |||
| architecture of the package. | |||
|
|
|||
| Typically, `BuildArch` only needs to be set when the package is | |||
There was a problem hiding this comment.
You might as well make the exact behavior and use clear and tie it back to Bazel definitions when the terms overlap. The points to make are
- If the package is really architecture independent, say "noarch"
- Otherwise specify a CPU architecture of the target platform your are building for.
- If you say nothing, it will default to the CPU arch of your execution platform.
Note that when cross compiling the target and execution platforms may not match.
|
|
||
| When no attribute is provided, this will default to your host's | ||
| architecture. This is usually what you want. | ||
|
|
||
| """, | ||
| ), | ||
| "target_architecture": attr.string( |
There was a problem hiding this comment.
Do we need both? I have not figured out the value of setting both, since only one gets used.
|
Friendly ping |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please consider a patch aimed to add proper support for constructing RPM packages aimed for the CPU architecture other than the host machine. This addresses #727 issue.
The current version of the "pkg_rpm"-rule exposes an "architecture"-option, which is meant to indicate the package's intended platform. Unfortunately, this option is being incorrectly utilized. It is being used to define the "BuildArch"-option in the RPM spec file. However, as per RPM packaging guide (https://rpm-packaging-guide.github.io/):
"'BuildArch' should be used if the package is not architecture dependent. For example, if written entirely in an interpreted programming language, set this to BuildArch: noarch. If not set, the package automatically inherits the Architecture of the machine on which it is built".
It appears that BuildArch is intended to represent either architecture of host machine or "noarch". Any efforts to designate an "alien" platform as a value for this field lead to a failure in the "rpmbuild"-utility, accompanied by an error message stating: "error: No compatible architectures found for build."
The purpose of this patch is to maintain backward compatibility while provide the solution for the described issue.
It preserves the existing "architecture"-attribute of the "pkg_rpm" rule, as it might already be in use by someone.
It introduces the "target_architecture"-attribute to the "pkg_rpm" rule, aiming to utilize it as a "arch"-suffix for the package name and to provide it to the "rpmbuild"-utility as the value for the "--target" option.