Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

On the other hand, though - creating this dependency *will* break workflows and cause many unexpected side-effects, as it broke mine last month: I have linux-headers-cloud-amd64 installed; when this package hit BPO, it brought in linux-image-cloud-amd64, which grub then tracked as the most recent kernel and booted into, causing (ironically) many drivers to be missing and the system failed to boot correctly as a result (it is not a cloud server, but it does build modules *for* cloud servers). It also brought my /boot to 98% full, fortunately this did not cause problems by itself, but obviously came close to doing so.

It has been consistently asserted that installing superfluous image files is harmless; I want to point out that this is anything but true, even aside from the more philosophical issues around having "source" packages depend on "binary" ones, and the precise meaning of "significant functionality" in the Debian policy.

Colm

On Tue, 2 Apr 2024 at 17:57, Colm Buckley <colm@tuatha.org> wrote:

Please explain. I am really sorry to be dragging this discussion out, but I honestly think there is some information I'm missing. Please tell me what I am missing here? ** PLEASE ** read it before replying; I am honestly not trying to undermine you, just point out a serious problem with the apparent logic.

Your proposal is to have linux-headers-X depend on linux-image-X.

But:

* User installs linux-image-X and linux-headers-X
* User builds modules for this image using DKMS or whatever
* User then does "apt install linux-image-Y" - this is the exact scenario you hope to guard against?
... nothing brings in linux-headers-Y; the user is *still* left without their new modules.

Your proposal will only work if the user remembers to upgrade -headers... which will fix the problem even without the dependency!

I fully understand that there is a desire for users to keep linux-image-* and linux-headers-* in synch; my proposal is that a *further* package be created - linux-complete-VERSION - which depends on both of them. Users who have that package installed would always have the right thing happen. To encourage adoption, it could be in "Suggests" from each, and maybe even in DKMS?

Colm

On Tue, 2 Apr 2024 at 17:51, Bastian Blank <waldi@debian.org> wrote:
On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote:
> ... but the proposed dependency wouldn't address that, right?

Actually it does. It ties all packages together with = dependencies.
For an upgrade, all packages need to be unpacked first and only then the
maintainer scripts can run.

There are cases where this can be broken, but working most of the time
is better then working never.

Bastian

--
Prepare for tomorrow -- get ready.
-- Edith Keeler, "The City On the Edge of Forever",
stardate unknown

--
Colm Buckley | colm@tuatha.org