Create toml overlay for kernel-headers

[rlmenge]

Introduces the kernel-headers component for Azure Linux 4.0, built from the CBL-Mariner-Linux-Kernel 6.18.5.1 source.

Uses the Fedora kernel-headers.spec as a base with overlays to:

1. Switch from Fedora's pre-built headers tarball to generating headers from Azure Linux kernel source
2. Set version to 6.18.5.1 targeting CBL-Mariner rolling-lts/mariner-3
3. Add build dependencies (make, gcc, perl, rsync)
4. Generate both native x86_64 and cross-compiled arm64 headers

Produces kernel-headers and kernel-cross-headerssubpackages.

[Copilot]

Pull request overview

This PR introduces the kernel-headers component for Azure Linux 4.0, which provides C header files for the Linux kernel userspace interface. The component uses Fedora's kernel-headers spec as a base and applies overlays to adapt it for Azure Linux's kernel source from CBL-Mariner-Linux-Kernel 6.18.5.1.

Changes:

• Creates kernel-headers component using Fedora rawhide spec with overlays to switch from pre-built headers to generating from Azure Linux kernel source
• Updates version from Fedora 6.19-rc8 to Azure Linux 6.18.5.1 targeting rolling-lts/mariner-3
• Implements build process to generate both native and cross-compiled headers (x86_64 ↔ aarch64)

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
base/comps/kernel-headers/sources	Adds SHA512 checksum for kernel-6.18.5.1.tar.gz source tarball
base/comps/kernel-headers/kernel-headers.spec	Base Fedora kernel-headers spec file (6.19-rc8) that will be modified by overlays
base/comps/kernel-headers/kernel-headers.comp.toml	Component configuration with overlays to adapt Fedora spec for Azure Linux: changes source to CBL-Mariner kernel, updates version to 6.18.5.1, adds build dependencies, and replaces install logic to generate native and cross-architecture headers

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

These comments describe how to create a pre-built headers tarball using Fedora/RHEL scripts, but the overlays in kernel-headers.comp.toml change Source0 to use the full Azure Linux kernel source instead of a pre-built headers tarball. These comments are now misleading and should be updated or removed to reflect that this component generates headers from the full kernel source during the build process.

Suggested change

	# This is a tarball with headers from the kernel, which should be created
	# using create_headers_tarball.sh provided in the kernel source package.
	# To create the tarball, you should go into a prepared/patched kernel sources
	# directory, or git kernel source repository, and do eg.:
	# For a RHEL package: (...)/create_headers_tarball.sh -m RHEL_RELEASE
	# For a Fedora package: kernel/scripts/create_headers_tarball.sh -r <release number>
	# Source0 is provided by the component configuration and points to the full
	# Azure Linux kernel source tree. This package generates the headers from that
	# source during the build process; no pre-built headers tarball is required.
	#
	# The actual Source0 URL or artifact name may be overridden by the build
	# overlays (for example, in kernel-headers.comp.toml).

[reubeno]

It looks like we're effectively gutting the upstream kernel-headers.spec (i.e., replacing all of %build and %install).

Given that, I could see an argument both ways for whether to overlay the upstream spec, or whether to just fully fork it and make it our own. I'm interested to get your take on it, but have left some comments throughout the .toml file regardless as general suggestions for the current approach.

[reubeno]

You should use the spec-add-tag overlay, e.g.:

[[components.mypackage.overlays]]
type = "spec-add-tag"
description = "Include a description here; it will become visible in some logging"
tag = "BuildRequires"
value = "some-devel-package"

There's an overlays.md file with examples like this, but it's not available on public GitHub yet. I can point you at it offline.

[reubeno]

Should we use %{azurelinux_version} in place of %{mariner_version} while we're at it?

[reubeno]

There are a few options for defining a macro like this. I'd actually recommend something like the following at the top of the file:

[components.kernel-headers.build]
defines = { "kernel_azurelinux_version" = "3" }

That will generate a macro definition without mutating the spec.

And ditto for the other %defines below.

[reubeno]

It's a toss-up, but you might consider using single-quoted TOML strings for the strings where there's content that would need escaping in double quotes. (And double-quoted strings like you've done above where there would need to be single-quoted content inside 😄 )

[reubeno]

It looks like this is just at the beginning of the %install section; did I get that right? (The regex replacements run the risk of being brittle in case the text being searched for changes upstream so I consider them a less-preferred option.)

If that's the case, then a spec-prepend-lines overlay could work here? e.g.,

[[components.kernel-headers.overlays]]
type = "spec-prepend-lines"
section = "%install"
lines = [
    ...
]

If you'd prefer not to have the lines chopped up, I think you can use a """-style string within a list. (That may be a readability/maintainability improvement for the other multi-line change above too, come to think of it.)

[reubeno]

Have we checked to see if the resulting RPM installs roughly the same files + dir structures as the upstream Fedora one, with these changes? Even if we take a different approach for composing it, I'd presume we would want to match the structure of the output.