debuginfo generation does not work with --build-in-place

[DaanDeMeyer]

Describe the bug

The %install to make debuginfo work is currently defined as follows on Fedora:

%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}

The --build-in-place documentation says:

       --build-in-place
              Build from locally checked out sources.  Sets _builddir to current working directory.  Skips handling of -n and untar in the %setup and the deletion of the buildSubdir.

Something in the interaction between these two causes debuginfo to not get generated when --build-in-place is used, presumably because buildsubdir is not defined when --build-in-place is used.

To Reproduce
Steps to reproduce the behavior:

1. Try to build a package that should produce debuginfo packages by using --build-in-place

Please link or attach the packages or spec files involved.

Expected behavior

Debuginfo packages are generated

Environment

• OS / Distribution: Fedora 39
• Version: RPM version 4.19.1.1

[DaanDeMeyer]

AFAIK for --build-in-place, %buildsubdir doesn't need to be defined. If I remove the check from the %install override, debuginfo packages are generated without problems.

[pmatilai]

--build-in-place is a hack that doesn't fit well into rpm's view of the world, I doubt debuginfo is the only thing that doesn't work with that. Thanks for the report though.

[DaanDeMeyer]

@pmatilai Is there by any chance a better way than --build-in-place to do builds using a local checkout of the sources? I'd be happy to switch to something else that fits more within rpm's view of the world if that exists.

[keszybz]

Actually, this is probably not the right tracker for this bug.
The problematic definition is from https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_302, so maybe it'd be better to file a bug against the package.

[DaanDeMeyer]

@keszybz I filed this here given #3040 and #3036 are going to move this into rpm itself

[pmatilai]

That %install definition is a bug in its own right: #2204 - yes, this is an upstream issue.

As for build-in-place alternatives, not really, the very concept of building from whatever happens to be around is alien to rpm's design of pristine sources.

[DaanDeMeyer]

@pmatilai We're using it as part of systemd's development workflow these days. Being able to incrementally build rpms from a locally checked out tree of the upstream repository allows us to incorporate package building in the development workflow itself. I can build an image with newly packaged systemd rpms from the latest upstream sources and boot it in a virtual machine in about 30s thanks to --build-in-place. Without --build-in-place we'd have to remove rpm from our development workflow entirely again, which I would hate to do because we get more useful test coverage by using rpm since our test images mimick regular distribution installs more compared to us doing meson install and hoping for the best.

It also makes debugging production issues a joy because I can make a source code change, get new rpms in 30s, install them, get more feedback, and do the same thing. This would also be a lot harder without --build-in-place.

(This does not take away that any proper rpm build intended to be distributed widely should always be done from pristine sources)

This is just some feedback on how this option makes my life a lot easier, so I'm hoping it won't get removed at some point because it conflicts with rpm's design.

[pmatilai]

I totally get the testing use-case, we have -bb --short-circuit for similar reasons. Only with --short-circuit we "poison" the produced packages to prevent people from distributing them (accidentally or otherwise).

Anyway, I agree there seems to be a bug - or more likely a few - in there. There are currently zero tests for --build-in-place, it basically just jumps off the cliff and hopes for the best. I'm more surprised it works at all as it is.

[DaanDeMeyer]

It's not the prettiest thing in the world but if you're interested in how we use --build-in-place, the build script that builds the development rpms in systemd can be found here

[keszybz]

Only with --short-circuit we "poison" the produced packages to prevent people from distributing them (accidentally or otherwise).

It is a misfeature. It means that the produced packages cannot be compared and tested properly. In particular, --short-circuit is very often used to tweak and test details of Obsoletes and Requires and such. Not being able to produce the package that looks exactly like the normal output makes the build not useful.

The whole idea of "prevent people from distributing them" doesn't make much sense. You cannot build a package with --short-circuit "accidentally". It's a very long option that you need to insert in the right place. And I guess "otherwise" means "maliciously" here, and that's even less useful, because the person doing the build has full control over what is built, so they don't need to use --short-circuit to achieve malicious goals.

Instead of using --short-circuit, people are forced to either wait for full package builds (which can be hours), or do dirty tricks like comment out part of the spec file. Those solutions are much worse (and much more likely to go wrong), than the problem being solved, i.e. people forgetting that they used --short-circuit and distributing those packages.

Please drop this whole protection and let people use --short-circuit without any limitations.