On Mon, Mar 20, 2017 at 08:46:20AM -0000, Mark Wielaard wrote:
Hi,
In case people didn't notice in the somewhat long analysis of the issue in the bug,
the workaround is just a simple oneliner:
diff --git a/kernel.spec b/kernel.spec
index cb3dec8..29c198a 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -183,6 +183,9 @@ Summary: The Linux kernel
%define _enable_debug_packages 0
%endif
%define debuginfodir /usr/lib/debug
+# Needed because we override almost everything involving build-ids
+# and debuginfo generation. Currently we rely on the old alldebug setting.
+%global _build_id_links alldebug
# kernel PAE is only built on i686 and ARMv7.
%ifnarch i686 armv7hl
Of course it would be nice if someone could cleanup the various places that the
kernel.spec overrides rpm find-debuginfo.sh and debugedit and provides some requirements
that would make this all easier for the kernel build. It looks like the current build does
a lot redundant extra work that might be prevented if rpm provided better hooks to do
automagically what the kernel spec build requires. One thing rpm wants to introduce in the
future (already upstream) is parallel processing of debug files. Which the current
kernel.spec seems to prevent because it serializes the processing itself already.
I would be happy to review any feedback on why the kernel.spec has the current hacks and
suggestions for improvements to make this smoother.
Hi Mark,
I can try and help explain some of the hacks. As I have been involved in
some of it over the past 11 years. Maybe with some history behind the
changes, we can make better decisions based on newer rpm technology?
To start, a bunch of the debuginfo-common hacks that Roland put in there 5-7
years ago was because the kernel was too big and we thought breaking them
up would make it easier to download kernel-debuginfo and
kernel-debug-debuginfo.
Of course this was back when rpm development was stale, so Roland just
choose the rpm macro route to do a lot of this work.
He also may have done some of it to prep for his build-id technology he
wanted to put into all the packages too.
Some of the other kernel.spec file hacks (debug files) were because the
kernel was ahead of the rpm curve. If rpm has implemented some of the
technology now, it would probably make sense to start using it.
I am not aware of some of those hacks being because rpm was broken, more
like rpm lacked the feature. Well except for the strict patching stuff,
rpm was broken and caused incorrectly patched kernel due to fuzzing.
Hope that helps.
Cheers,
Don