[Rpm-ecosystem] Trying to understand %buildsubdir and debuginfo generation

[Mark Wielaard]

Hi,

On Fri, 2018-04-27 at 11:34 +0300, Panu Matilainen wrote:
> On 04/27/2018 06:47 AM, Jason L Tibbitts III wrote:
> > Here's a paste from the macros that Fedora uses
> > (/usr/lib/rpm/redhat/macros):
> > 
> > %install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
> > %%install\
> > %{nil}
> 
> Ew. Now there's a blast from the past, that ugly %install override is 
> from 2002 when debuginfo was a fairly new concept. If that's actually 
> needed for debuginfo then it's a bug (in rpm).

I admit to not precisely know the macro expansion rules or when, what
defines buildsubdir. (I always assumed just having a %setup macro was
enough to get it defined). But I do know why the buildsubdir macro is
necessary for autogenerating debuginfo/sources packages.

The idea is that the debuginfo comes from the (installed) binaries, it
gets stripped out and put into separate (.debug) files which get
packaged together with some auxiliary information generated by the
debuginfo scripts (like .dwz files).

This debug information might reference source code files. For some
profiling/tracing/debugging applications having access to the
(generated) source files might be helpful. But you only want to package
up the actual source files used to generate the binaries. So those that
are actually referenced in the debuginfo, not other files that might be
in the srpm but never used, nor source/include files from other (devel)
package that happen to be installed.

To know which source files to package the source named in the .debug
files needs to be matched against the actual source files (produced) by
the package. To do that you will need to know the buildsubdir. Only
files inside the buildsubdir should be packaged as debugsources. e.g.
the debuginfo might also reference /usr/include/stdio.h, but you don't
want that packaged.

Also in the future packages might be build with -gsplit-dwarf which
places (most) debug information in separate .dwo files, which will
never be installed, but will be kept in the buildsubdir from which it
will have to be fetched and packaged.

Cheers,

Mark