The debuginfo machinery breaks if %install follows directly after %prep or preamble

[eclipseo]

Hi,

When building noarch subpackages, adding a section %generate_buildrequires will trigger the search for the debuginfo data. It should not.

Mail ref:

Yes I know, but not in this case as go libraries are noarch.
The problem that when we add the %generate_buildrequires section, it triggers the detection of the debug info. Without it, the detection of debug info is skipped so the package builds normally. I don't know what is the expected behavior.

Okay, this wasn't quite so clear in the initial context. %generate_buildrequires should not trigger the debuginfo machinery, that's a bug of some sort. Please file a ticket at https://github.com/rpm-software-management/rpm

- Panu -

[eclipseo]

Slight tiny bump.
Any info on the source of this issue?

[ffesti]

Do you have a link to an example?

[gotmax23]

@ffesti, you can look at https://src.fedoraproject.org/rpms/golang-x-net/blob/rawhide/f/golang-x-net.spec. It only has one noarch subpackage. (%gopkg generates the subpackage definitions). When using static BuildRequires it builds fine, but when using %generate_buildrequires it fails with error: Empty %files file debugfiles.list and requires %global debug_package %{nil}. You can use go2rpm -f https://github.com/golang/net --commit 0bcc04d9c69b4e379010f97e15bb7751dc57156b -R golang.org/x/net to generate the same specfile as linked above but with static BuildRequires.

[pmatilai]

Oh, this one's rather special.

Debuginfo processing triggers when two conditions are met: the package is not a noarch package, and there is no %build section. For whatever reason, the main package here is arch specific instead of noarch, and so the first condition is met (noarch sub-packages are a wacko special case in rpm and do not count for this purpose at all). That package has no %build section at all, and that is how it avoids the debuginfo machinery in the first place, but apparently %generate_buildrequires counts as a "build script" for the purposes of that check. Maybe there's a fallthrough switch-case someplace, dunno. But that does indeed seem like a clear-cut bug.

[pmatilai]

Ehm, scratch the above, the debuginfo stuff is hooked on %install, not %build. Sorry for the misleading comment.

This seems one of those "spec specials", really. It's probably some interplay between how the spec parser works and expands macros and sections - if you move the %generate_buildrequires section before %prep in the golang-x-net.spec case, the phenomenon disappears.

[pmatilai]

Yup. The reason I remembered debuginfo depending on %build section is easily demonstrated with the golang example too (after removing the line to disable debuginfo):

1. move %generate_buildrequires before %prep, debuginfo disappears
2. add (an empty) %build section between %prep and %install, and debuginfo reappears
3. remove the empty %build section, debuginfo disappears
4. move the %check section before %install, debuginfo reappears

So the ugly hack of debuginfo enabling (see #2204) relies on some rather subtle spec parser quirks, and does not work after %prep because that's processed differently from other sections, ditto for preamble.

And as noted, this is an arch-specific package so debuginfo should be generated for it, unless disabled. But I guess debug extraction still doesn't work for golang (?) so disabling it for this is the right thing to do, regardless of all the weird stuff that the spec parser is throwing at you.

This is one weird ticket 😆

[ffesti]

OK, I think I have an idea what's wrong here:

If %install is encountered after/as part of %prep debuginfo does not work. The reason is that %prep is first parsed and %setup - which is setting %buildsubdir - is only executed after the whole %prep section is processed and all macros are expanded.
As a result %buildsubdir is not yet set when %install is encountered and expanded into the debuginfo magic. But the debuginfo foo checks for %buildsubdir as it probably needs that.

So, %generate_buildrequires is an innocent bystander here and the golang-x-net package relied on the broken behavior to "switch off" debuginfo creation.

Two things are to fix here:

• Bringing sanity to the debuginfo hacks (Properly upstream debuginfo enablement #2204)
• Turn %setup and %patch at least into proper internal macros (yes, we tried before and it's not that easy)

[gotmax23]

Golang library packages often don't ship any go binaries and thus no arched (sub)packages, but they're built on all arches to ensure that the tests pass everywhere and that the noarch -devel subpackage does not contain different contents when built on different architectures. Rust libraries work similarly and also have to disable debuginfo like this. For Go application packages (e.g. hugo or containerd) that build binaries and thus ship arched RPMs, debuginfo extraction works just fine. There's just nothing to extract if no bianries are built.

[ffesti]

I wonder if adding %end to the %install macro fixes the issue. The %end would be useful for once...

[gotmax23]

What does %end do?

[ffesti]

It closes a section. So it would end the %prep section. Idea is that the debuginfo magic wold then be evaluated after the prep section. Basically the same as if there was another section inbetween.

[pmatilai]

Adding %end works for terminating %prep, but it doesn't help %install following the preamble.
The proper fix for this is to eliminate the %install override macro hack.

[ffesti]

Well, %install following the preamble is technically a different issue. %prep is setting %buildsubdir via %setup and everything that makes use of that needs to be after %prep. This is not limited to the debuginfo magic - although it is especially non-obvious there.

[pmatilai]

Oh, I forgot that %buildsubdir dependency, which what explains not working before %prep. Tricksy 😄

And @gotmax23 - that Golang (and others) do not have debuginfo is yet another, separate matter. Like said, for now the right thing to do is to explicitly disable the debuginfo package in the spec for such cases.

[gotmax23]

And @gotmax23 - that Golang (and others) do not have debuginfo is yet another, separate matter. Like said, for now the right thing to do is to explicitly disable the debuginfo package in the spec for such cases

Go binaries do have debuginfo. Go libraries are just source code, i.e. text files.

[pmatilai]

Well, those that do have no problem. Those that don't, should be "BuildArch: noarch" in the main package and no debuginfo will be attempted on them. Sub-package level noarch is a special case to allow shared noarch content in an otherwise arch dependent package. The golang package abuses that for it's own reasons (I'm sure there are some) at the cost of requiring packages to disable debuginfo manually.

[pmatilai]

Fixed by #2730

And no, don't ask for backports (see the part about sacrifices in the PR). This will only be in rpm >= 4.20.