Define %{debugbuildsenabled} consistently

The scripts in this repository set DEBUG_BUILDS_ENABLED this way:

if [ "$SNAPSHOT" = 0 ]; then
	# This is based off a tag on Linus's tree (e.g. v5.5 or v5.5-rc5).
	# Two kernels are built, one with debug configuration and one without.
	DEBUG_BUILDS_ENABLED=1
else
	# All kernels are built with debug configurations.
	DEBUG_BUILDS_ENABLED=0
fi

But the SPEC file says instead:

# Set debugbuildsenabled to 1 for production (build separate debug kernels)
#  and 0 for rawhide (all kernels are debug kernels).
# See also 'make debug' and 'make release'.

Which behavior is actually intended?

In my opinion: within Rawhide, the meaning of the package names should not be altered from build to build, depending on whether the upstream source is a snapshot or not. If someone is using Fedora Rawhide to determine if a bug is fixed in the current kernel development cycle, they should not expect the debugging options to change when upgrading from kernel-5.12.0-0.rc6.20210408git454859c552da.186.fc35 to kernel-5.12.0-0.rc7.189.fc35 to kernel-5.12.0-0.rc7.20210416git7e25f40eab52.191.fc35. If they knew to install kernel-debug-5.12.0-0.rc7.189.fc35 instead, that package does not upgrade to kernel-5.12.0-0.rc7.20210416git7e25f40eab52.191.fc35. There should be consistency. The fact that some of these are based on upstream "releases" and others are not does not matter, when they are all being tagged and uploaded to the same package repository.

I assume the reason that this option is not always set to '1' is because of the additional overhead of building non-debug packages, while still having a desire to occasionally build them (perhaps for additional testing). It seems there are better ways to do this though. I would suggest either:

  • following the same scheme in Rawhide as in branched versions, where debug packages are named kernel-debug; or
  • using an inverted naming scheme in Rawhide, where non-debug packages are named kernel-nodebug

and either way, building snapshot versions using --with-dbgonly or equivalent.

Thoughts appreciated. Regardless, the SPEC file and the build scripts should be describing the same behavior.

Edited by David Ward