Add support for generating debuginfo RPMs #842
Conversation
This change enables the creation and capture of debuginfo RPMs on Fedora40 and CentOS7. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/ Fedora 40 expects the RPM contents to be located in a subdirectory which is specified using the `buildsubdir` variable. In order to account for this, we need to tweak some of the location details if debuginfo is enabled. CentOS expects `buildsubdir` to have a value like `.` instead. In both cases, we disable debugsource packages by ensuring that we undefine `_debugsource_packages`, otherwise we'll try to generate them alongside the debuginfo packages and will fail. We only want this method of producing debuginfo to apply when we're using the system `rpmbuild` because the underlying behaviour is controlled by a combination of the rpmbuild version, macro definitions, find-debuginfo.sh, and debugedit. If we were to expand this to use a hermetic debuginfo then a different approach might be desirable.
This provides a basic example that generates a debuginfo RPM configured to run on CentOS7.
rules_python seems to fail us when we're generating debuginfo RPMs unless we upgrade to a version more recent than 0.24.0.
In lieu of enabling this behaviour by default on the supported platforms, we add an additional argument to the pkg_rpm() rule that will allow us to enable it for pkg_rpm() targets. This prevents us from enabling it in cases where it's not desired.
This test is modelled on the subrpm test. In lieu of using a simple text file as an input it instead generates a binary that includes debug symbosl from a C source file and includes that in the RPM. The baseline comparison strips out the `.build-id` paths because the hashes that are generated may not be stable.x
These values may vary depending on the platform that this is being run on and we don't really care about them.
|
I'm going to be slow to respond. Every hour of this week is booked. |
Thanks for the heads up |
|
@aiuto any cycles to go over this in the near term? |
pkg/rpm_pfg.bzl
Outdated
| doc = """Enable generation of debuginfo RPMs | ||
|
|
||
| For supported platforms this will enable the generation of debuginfo RPMs adjacent | ||
| to the regular RPMs. Currently this is supported by Fedora 40 and CentOS7 |
There was a problem hiding this comment.
. at the end of the docstring.
There was a problem hiding this comment.
I have an overall question.
I was curious why you passed debuginfo_type via the toolchain, instead of just getting the os type in make_rpm.py. Then I saw you need to change the stanza to add a .. in a path. sigh.
But it leads to the question of the name of debuginfo_type. Is it really distinguishing the format of the debuginfo, or is it really a distinguisher of the target os?
If you could build for fedora from centos, should it be an attribute of the rule rather than picked up as a side effect in the toolchain?
Are there other constraints or information about cross building which should make sense in the docstring?
overall the code looks reasonable.
tl;dr I don't think I can assert anything about cross building with this at all, unfortunately :( We're relying on the system rpmbuild for this which means that we're also relying on the various rpm macros and and supporting tools in place that belong to the system that we're building on. Can definitely clarify some of how this works in the docstring, however. |
Done |
CentOS Stream 9 appears to work more or less the same for debuginfo generation as CentOS 7. `os-release` describes it as os == `centos` and version == `9`. This change creates an extra token for `centos9` and sticks it in the places where we currently have controls for `centos7`.
|
Sorry for the late merge. Hugely busy weekend. |
This change enables the creation and capture of debuginfo RPMs on
Fedora40 and CentOS7.
See:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/
Fedora 40 expects the RPM contents to be located in a subdirectory
which is specified using the
buildsubdirvariable. In order toaccount for this, we need to tweak some of the location details if
debuginfo is enabled.
CentOS expects
buildsubdirto have a value like.instead.In both cases, we disable debugsource packages by ensuring that we
undefine
_debugsource_packages, otherwise we'll try to generate themalongside the debuginfo packages and will fail.
We only want this method of producing debuginfo to apply when we're
using the system
rpmbuildbecause the underlying behaviour iscontrolled by a combination of the rpmbuild version, macro
definitions, find-debuginfo.sh, and debugedit. If we were to expand
this to use a hermetic debuginfo then a different approach might be
desirable.