lib / kernel-debs: add Conflicts:linux-image to kernel deb pkg

[leggewie]

we do not want the user to install an upstream kernel package

Summary by CodeRabbit

• Chores
  • Updated package conflict metadata for the linux-image package.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The change adds a Conflicts: linux-image field to the Debian control file generated for the linux-image package during kernel compilation. This packaging metadata modification prevents concurrent installation of conflicting linux-image versions. No changes to build logic or control flow.

Changes

Cohort / File(s)	Summary
Debian control metadata lib/functions/compilation/kernel-debs.sh	Adds Conflicts: linux-image field to the linux-image package control file

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

A conflict so clear, so neatly defined,
Linux-image meets its match—their versions aligned,
No more tangled packages in the Debian domain,
A simple field brings order and peace to the chain! 🐰✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: adding a Conflicts field to the kernel deb package control file.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between dd44469 and 2c87a4a.

📒 Files selected for processing (1)

• lib/functions/compilation/kernel-debs.sh (1 hunks)

🧰 Additional context used

🧠 Learnings (11)

📚 Learning: 2025-09-27T21:47:58.020Z

Learnt from: tabrisnet
Repo: armbian/build PR: 8678
File: config/kernel/linux-bcm2711-edge.config:859-861
Timestamp: 2025-09-27T21:47:58.020Z
Learning: In the Armbian build system, kernel configuration files in config/kernel/ are generated through an automated process: taking previous config → applying scripted changes from armbian-kernel.sh → running kernel's `make oldconfig` → processing by Armbian machinery back into config files. This automated process properly handles kernel configuration dependencies and reduces the likelihood of manual configuration errors.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-09-27T21:50:04.845Z

Learnt from: tabrisnet
Repo: armbian/build PR: 8678
File: config/kernel/linux-sm8250-edge.config:80-82
Timestamp: 2025-09-27T21:50:04.845Z
Learning: In the Armbian build system, kernel configuration files are generated through this automated process: taking previous config → applying scripted changes from armbian-kernel.sh → running kernel's `make oldconfig` → processing by Armbian machinery back into config files. This automated process properly handles kernel configuration dependencies and reduces the likelihood of manual configuration errors.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-04-30T16:16:47.150Z

Learnt from: The-going
Repo: armbian/build PR: 8147
File: config/sources/families/include/sunxi64_common.inc:38-39
Timestamp: 2025-04-30T16:16:47.150Z
Learning: The Armbian build system references Linux kernel versions in the form "tag:v6.14.4" in the KERNELBRANCH variable, even when point release tags might not be directly visible in the upstream repository in the same form.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-11-10T22:05:40.490Z

Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-06-25T03:42:09.086Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-05-05T12:35:07.143Z

Learnt from: Grippy98
Repo: armbian/build PR: 8152
File: lib/functions/configuration/interactive.sh:209-266
Timestamp: 2025-05-05T12:35:07.143Z
Learning: For the interactive kernel selection in Armbian, KERNEL_MAJOR_MINOR and KERNEL_DESCRIPTION are parsed from family.conf but deliberately not set as environment variables to avoid potential interference with other parts of the build system.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-08-21T08:10:59.502Z

Learnt from: leggewie
Repo: armbian/build PR: 8524
File: config/boards/orangepi2.csc:6-6
Timestamp: 2025-08-21T08:10:59.502Z
Learning: Not all Armbian boards support all kernel versions (legacy, current, edge). Some boards may only support specific kernel versions due to hardware limitations or lack of mainline support, which is why their KERNEL_TARGET contains only the supported options (e.g., just "legacy").

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-06-24T10:08:40.313Z

Learnt from: EvilOlaf
Repo: armbian/build PR: 8328
File: lib/functions/compilation/patch/drivers_network.sh:542-545
Timestamp: 2025-06-24T10:08:40.313Z
Learning: In the Armbian build system, when a PR removes build support for a specific kernel version, version check issues for that removed version become practically irrelevant even if they appear incorrect in isolation. Context about which kernel versions are being deprecated/removed is important for understanding the impact of version-related code changes.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-11-02T20:49:56.719Z

Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-12-12T23:10:00.819Z

Learnt from: tabrisnet
Repo: armbian/build PR: 9058
File: config/sources/families/spacemit.conf:39-45
Timestamp: 2025-12-12T23:10:00.819Z
Learning: In the Armbian build system, vendor kernel forks can use "vendor-edge" branch naming for bleeding-edge or pre-release vendor kernels, as demonstrated in config/sources/families/k3.conf. The typical vendor branch naming pattern is: "vendor" or "vendor-rt" for stable vendor releases, and "vendor-edge" for bleeding-edge/pre-release vendor versions. The "edge" naming without "vendor-" prefix is reserved for mainline kernel branches.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

📚 Learning: 2025-09-14T06:29:18.958Z

Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.

Applied to files:

• lib/functions/compilation/kernel-debs.sh

🔇 Additional comments (1)

lib/functions/compilation/kernel-debs.sh (1)

269-269: Remove contradictory package specification flag — this Provides/Conflicts pattern is standard Debian practice.

A special exception exists in Debian for packages declaring a conflict with a virtual package they provide, which is intentional and allows a package to conflict with other providers. This is the recommended approach for virtual packages that should have only one provider installed at a time.

The combination of Provides: linux-image and Conflicts: linux-image effectively prevents co-installation of upstream kernel packages (like linux-image-generic or linux-image-virtual) by conflicting with the shared virtual package they all provide. This approach is more robust than listing specific package names.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[rpardini]

Absolutely not. One can have as many linux-image's as one wants.

[leggewie]

It is/was my understanding that this is Armbian policy. Only a single kernel and only an Armbian kernel.

@igorpecovnik Can you clarify? I am happy to close this PR once it is clear what Armbian policy actually is. It is my recollection that you made a statement somewhere, possibly in a private chat, along the lines of what I characterized above. And I can certainly see an argument to be made for something like it, just like I can also see an argument be made against it.

[EvilOlaf]

To my understanding it was never a policy that there must be one kernel only. We just never went into multi-kernel-world on stock images.

[igorpecovnik]

We just never went into multi-kernel-world

That, well said.

[rpardini]

Reiterate: all images using GRUB (uefi-*, jetson-nano, a few others others) already support booting multiple kernels due to GRUB allowing choice at boot.

Building with EXT=u-boot-menu allows for multiple kernels using extlinux; on platforms where u-boot supports HDMI & USB (eg meson64) that allows for choice at boot using standard console. For others, serial console is required.

All upstream Debian and all upstream Ubuntu allow for multiple kernels.

absolutely nothing is gained by adding this restriction.

I can't fathom why were still discussing it. It also appears in different PRs in other forms.

[igorpecovnik]

Then closing now.