Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #81958 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-28 18:30 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-28 18:40 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-02-29 11:40 +0100
      Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-29 12:20 +0100
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-02-29 12:30 +0100
          Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-02-29 13:20 +0100
            Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-02-29 13:40 +0100
              Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-04-06 09:52 +0200
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-29 12:40 +0100
    Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64  incorrectly depends on the corresponding linux-image-amd64 package "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-02-29 11:40 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-29 15:40 +0100
      Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-03-02 01:50 +0100
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-03-04 11:40 +0100
          Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-03-04 12:40 +0100
            Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-03-04 14:00 +0100
              Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-03-06 15:20 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-03-04 11:10 +0100
    Bug#1064976:  colm <colm@tuatha.org> - 2024-03-07 12:30 +0100
    Bug#1064976:  Colm Buckley <colm@tuatha.org> - 2024-03-14 11:00 +0100
    Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-* Colm Buckley <colm@tuatha.org> - 2024-03-19 13:40 +0100
      Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-* Luca Boccassi <bluca@debian.org> - 2024-04-06 09:52 +0200
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-04-06 09:50 +0200
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-04-06 09:50 +0200
      Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-04-06 09:51 +0200
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: Having headers depend on image - bad idea I think Bastian Blank <waldi@debian.org> - 2024-04-06 09:50 +0200
    Bug#1064976: Having headers depend on image - bad idea I think Colm Buckley <colm@tuatha.org> - 2024-04-06 09:50 +0200
    Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64  incorrectly depends on the corresponding linux-image-amd64 package "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:50 +0200
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-04-06 09:50 +0200
    Processed: Re: linux-headers-amd64: linux-headers-* incorrectly  depends on linux-image-* "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: Having headers depend on image - bad idea I think Colm Buckley <colm@tuatha.org> - 2024-04-06 09:51 +0200
    Processed: Having headers depend on image - bad idea I think "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package) Bastian Blank <waldi@debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-04-06 09:51 +0200
    Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64  incorrectly depends on the corresponding linux-image-amd64 package) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: Sad user. Colm Buckley <colm@tuatha.org> - 2024-05-16 23:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#82175 — Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*

[Multipart message — attachments visible in raw view] — view raw

Control: tags -1 patch

On Tue, 19 Mar 2024 12:32:16 +0000 Colm Buckley <colm@tuatha.org>
wrote:
> Package: linux-headers-amd64
> Version: 6.6.13-1~bpo12+1
> Followup-For: Bug #1064976
> X-Debbugs-Cc: colm@tuatha.org
> 
> Can I suggest in the interim that Depends: be replaced with
Recommends:
> or Suggests: given that most installations won't actually need the
image
> package?

MR to downgrade to recommends:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/1054

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#82146

On Tue, 2 Apr 2024 at 16:52, Bastian Blank <waldi@debian.org> wrote:
>
> On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote:
> > Let's look at this the other way around: if there was no dependency, in
> > what scenario would things break and how?
>
> - linux-headers-bla and linux-image-bla are installed
> - linux-image-bla is uipgraded
> - no modules will be built, because the matching headers are missing

Got it, thanks, that makes sense to me as a problem and it would be
good to solve.

Is the root cause that the image and the headers package are published
and uploaded separately, due to signing?

[toc] | [prev] | [next] | [standalone]

#82149

On Mon, Apr 01, 2024 at 09:25:40PM +0000, Luca Boccassi wrote:
> Why do dkms modules need the image installed to be built? At the very
> least they didn't use to, the headers were enough last time I had to
> deal with that stuff for the nvidia drivers

dkms is used to build modules for the kernel that is just being
installed.  To do that it needs also the headers in matching versions.

As the image can't depend on the headers, some other way was needed.

Bastian

-- 
Spock: We suffered 23 casualties in that attack, Captain.

[toc] | [prev] | [next] | [standalone]

#82154

On Tue, 2 Apr 2024 08:27:39 +0200 Bastian Blank <waldi@debian.org>
wrote:
> On Mon, Apr 01, 2024 at 09:25:40PM +0000, Luca Boccassi wrote:
> > Why do dkms modules need the image installed to be built? At the
very
> > least they didn't use to, the headers were enough last time I had
to
> > deal with that stuff for the nvidia drivers
> 
> dkms is used to build modules for the kernel that is just being
> installed.  To do that it needs also the headers in matching
versions.
> 
> As the image can't depend on the headers, some other way was needed.

Sorry, I am still unable to understand the issue: dkms can and does
build modules for all installed _headers_ (plural). The fact that the
headers pull in a corresponding image does not change that fact, as far
as I can tell. In fact, it doesn't need any images at all, again as far
as I know.

Let's look at this the other way around: if there was no dependency, in
what scenario would things break and how?

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#82163

On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote:
> Let's look at this the other way around: if there was no dependency, in
> what scenario would things break and how?

- linux-headers-bla and linux-image-bla are installed
- linux-image-bla is uipgraded
- no modules will be built, because the matching headers are missing

Bastian

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
		-- Commander Kor, "Errand of Mercy", stardate 3201.7

[toc] | [prev] | [next] | [standalone]

#82150 — Bug#1064976: Having headers depend on image - bad idea I think

Hi

On Tue, Apr 02, 2024 at 03:26:32PM +0000, Colm Buckley wrote:
> This is a real problem - however I think it is *not* one which the change
> in dependency addresses; even if -headers-Y depends on -image-Y, step 3
> above will proceed without any conflicts (because the reverse dependency is
> not true). I think the only realistic way to address this (assuming we
> don't want to make -image depend on -headers) would be to have a
> linux-complete (not sold on the name) package series which depends on
> corresponding versions of both image and headers packages. Users who
> regularly build new modules should be encouraged to install this package
> and have it pull in suitable versions of both headers and image.

No, there is no "correct" solution.  Anything correct would need not
only moving the dependencies, but also the maintainer scripts, into one
package.  This is not going to be done without major restructuring.

So as long as there is no concept and support for that it will remain a
somewhat working solution.

Regards,
Bastian

-- 
Change is the essential process of all existence.
		-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2

[toc] | [prev] | [next] | [standalone]

#82151 — Bug#1064976: Having headers depend on image - bad idea I think

[Multipart message — attachments visible in raw view] — view raw

I wrote:

[...] From the maintainer's most recent comments, I believe that the
> problem is something like:
>
> * user has installed linux-headers and linux-image for kernel version X
> * user has built additional modules using DKMS which are installed into
> the running system
> * user upgrades linux-headers to version Y, new modules get rebuilt
> * user does not upgrade linux-image from X to Y, confusion results
>
> Having linux-image-Y be a dependency of linux-headers-Y does indeed
> address this problem, but [...]
>

The most recent comment (
https://lists.debian.org/debian-kernel/2024/04/msg00020.html) from the
maintainer indicates that he has a slightly different problem in mind:

* user has installed linux-headers and linux-image for version X
* user has built additional modules using DKMS, installed into the running
system
* user upgrades the *kernel image* to version Y but forgets to upgrade the
headers
* as a result, new kernel is missing important modules, confusion reigns

This is a real problem - however I think it is *not* one which the change
in dependency addresses; even if -headers-Y depends on -image-Y, step 3
above will proceed without any conflicts (because the reverse dependency is
not true). I think the only realistic way to address this (assuming we
don't want to make -image depend on -headers) would be to have a
linux-complete (not sold on the name) package series which depends on
corresponding versions of both image and headers packages. Users who
regularly build new modules should be encouraged to install this package
and have it pull in suitable versions of both headers and image.

Is this correct, Bastian? I'm sorry for taking so long to understand what
problem was being addressed here.

Colm


-- 
Colm Buckley | colm@tuatha.org

[toc] | [prev] | [next] | [standalone]

#82152 — Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

Processing control commands:

> tags -1 wontfix
Bug #1064976 [linux-headers-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Added tag(s) wontfix.

-- 
1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82156

On Mon, 1 Apr 2024 at 21:49, Bastian Blank <waldi@debian.org> wrote:
>
> Control: tags -1 wontfix
>
> On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote:
> > On Thu, Feb 29, 2024 at 12:12:21PM +0000, Luca Boccassi wrote:
> > > With the new vmlinux.h shipped in the headers package, the BTF case
> > > should be covered.
>
> As said, this dependency is to make sure kernel modules are properly
> built.  vmlinux.h is not for kernel modules.

Why do dkms modules need the image installed to be built? At the very
least they didn't use to, the headers were enough last time I had to
deal with that stuff for the nvidia drivers

[toc] | [prev] | [next] | [standalone]

#82157 — Processed: Re: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*

Processing control commands:

> tags -1 patch
Bug #1064976 [linux-headers-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Added tag(s) patch.

-- 
1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82158 — Bug#1064976: Having headers depend on image - bad idea I think

[Multipart message — attachments visible in raw view] — view raw

Control: reopen 1064976

My apologies for the ping-pong; I do want to keep this open until the
discussion has completed. I will set out my thoughts below. I'm afraid this
is fairly long.

A brief history of this issue: in December 2023, the control file for
linux-headers-* was altered to include a dependency on linux-image-* (
https://salsa.debian.org/kernel-team/linux/-/merge_requests/903). As far as
I can tell, no bugreport was linked as a problem being addressed with this
change; the maintainer's comment was "A lot of problems arise if users use
headers of a different version then the associated image. The easiest
solution is to make them depend." Note that this dependency did not exist
in any previous version of linux-headers as far as I can determine; the
problems seem to be largely theoretical.

This change worked its way through the release pipeline and eventually
arrived in bookworm-backports around the end of February 2024, with the
promotion of the package linux-headers-6.6.13+bpo-amd64 (and others) to
backports. I immediately noticed the impact on my build server, and
submitted a bug report (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976) requesting that
it be reverted.

The maintainer defended the change, indicating that it was necessary for
people using dkms; when pressed on exactly what failed, he mentioned the
BTF warnings [1] but as far as I can tell, no specific user problem was
presented. Several attempts by myself and Luca Boccassi to determine what
problem was being addressed were not answered.

The bug was closed as WONTFIX a few days ago, but still there has been no
real explanation as to why the change was introduced in the first place. I
would like to go on the record here as saying (especially with the xz-utils
exploit still in everyone's memory), that we should be *extremely careful*
with changing things like dependency trees without very well-documented
reasons, *especially* for something as critical as the kernel packages. I
ordinarily try to be very respectful of maintainers' latitude and
discretion in packaging decisions, but here I am trying to ensure that a
serious problem is addressed in BPO before it gets promoted to stable. The
change is significant enough that I feel it deserves more discussion  and
attention than it has so far received.

Having re-read the thread a few times today, I feel that the BTF warnings
(which were originally presented as the main reason for this change) are a
red herring and not relevant. The new packaging of vmlinux.h does address
the issue of BPF builds for pretty much all users (it's true that build
pipelines will have to be adjusted, but the new system is a significant
improvement on the old). The discussion about BPF kernel modules does not
seem to be based on any real user activity, and to be honest it seems
somewhat self-contradictory - why would a kernel module need BPF in the
first place?

Let's consider the possible reasons for having the header package depend on
the image package:

From Debian's policy documentation; "The Depends field should be used if
the depended-on package is required for the depending package to provide a
significant amount of functionality." So what functionality is provided by
linux-headers-*? I would posit initially that their main function is
unspecified apart from "having the header files for the specific kernel
exist under /usr/src", which clearly does not require the image package.

However, a major use case for the header files is to build kernel modules,
whether using DKMS or some other mechanism. But this use case *also* does
not require the image package; in fact this is the main reason the header
files were packaged as they are. Hundreds of thousands (at least) of Debian
users have been happily building kernel modules using linux-headers
packages without the corresponding image files for decades, and there are
no recent kernel changes which break this ability. The recent introduction
of vmlinux.h additionally addresses an edge case (building BPF programs)
which formerly *did* require a built image for its symbol table. So the
important piece of functionality also does not require the kernel image
package.

Now, given the maintainer's comments on the original PR and in this bug, I
suspect I understand the real reason for the change: in order to *run*
modules built using DKMS etc., obviously the corresponding kernel image
file needs to be present. From the maintainer's most recent comments, I
believe that the problem is something like:

* user has installed linux-headers and linux-image for kernel version X
* user has built additional modules using DKMS which are installed into the
running system
* user upgrades linux-headers to version Y, new modules get rebuilt
* user does not upgrade linux-image from X to Y, confusion results

Having linux-image-Y be a dependency of linux-headers-Y does indeed address
this problem, but I feel that it is fairly substantial overkill. There are
several referenced in the bug thread to DKMS *needing* the image file, but
I honestly don't know what these are - to the best of my knowledge it has
always been possible to build kernel modules using only linux-kbuild and
linux-headers; linux-image is not needed. I am of course willing to be
corrected on this point.

The reasons I feel it is *not* sensible:

* It makes a sudden, large change to the dependency tree of any systems
with linux-headers-ARCH already installed; when this change ends up in
stable, many systems will find sudden new dependencies being installed,
with potentially serious consequences.

* It makes a (largely) source package depend on a substantial binary
package, which in turn can seriously alter the way a system operates -
installing a new kernel into /boot might overflow a small partition, or
might trigger a substantial chain of additional installation scripts, which
will generally not be expected by someone expecting just to install some
source headers.

* It addresses a largely theoretical issue - a user who is competent enough
to build kernels using DKMS but not competent enough to realize that they
need the corresponding kernel image - which as far as I can see has not
been reported by any Debian users.

* It assumes that the only use case of linux-headers is to build modules
*for the current system* and actively subverts other use cases, such as
having headers present for reference only, or build servers which build
modules for distribution to other systems.

* It seems to go against the spirit of the Debian packaging policy which
says that Depeds implies "significant functionality" is missing absent the
depended package. I posit that this is simply not the case in the
relationship between linux-headers and linux-image.

The maintainer has invited proposals for alternative solutions to address
the runtime concern; here are my proposals; roughly in decreasing order of
preference:

1) Downgrade the Depends: relationship to Recommends: as proposed in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1054 - the
default behavior of apt is to install Recommended packages as though they
were hard dependencies, so for most users they will be equivalent. I posit
that users who are likely to fall into the "competence interval" above are
also less likely to have modified the apt installation defaults, so this
should address the issue. I do not understand the maintainer's reasons for
rejecting this PR.

2) Introduce a new package called "linux-complete-VERSION" which depends on
linux-image-VERSION and linux-headers-VERSION. Users who require that their
headers and image files be always installed in synch can install this
package, without suddenly changing the behavior of systems with
linux-headers already installed.

3) Move the linux-headers installation entirely to source packages, and
eliminate them from the binary distribution. This would be a substantial
policy change, but could in theory allow for a fairly complete separation
of use cases.

4) Change the dependency of linux-headers as proposed by the maintainer,
but introduce a further package called linux-headers-only or similar which
does not have the dependency. This has several downsides; an inelegant
naming scheme and dependency chain, possible duplication of installation
trees, and a sudden change in the behavior of existing installations.

I welcome the thoughts of the community.

Colm




[1] If the kernel image file is not present, the legacy mechanism for
extracting symbols for BTF builds does not work; this is the same issue
which was addressed with vmlinux.h in
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005

[toc] | [prev] | [next] | [standalone]

#82159 — Processed: Having headers depend on image - bad idea I think

Processing control commands:

> reopen 1064976
Bug #1064976 {Done: Colm Buckley <colm@tuatha.org>} [linux-headers-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Bug reopened
Ignoring request to alter fixed versions of bug #1064976 to the same values previously set

-- 
1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82160 — Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package)

On Mon, Apr 01, 2024 at 08:39:06PM +0000, Debian Bug Tracking System wrote:
> No.  We need to make sure someone installing linux-image-bla and
> linux-headers-bla have the same version, so the modules are compatible.

Revisiting this bug, I might have been not explicit enough.  This
dependency is needed, so headers and kernel will be available in the
same version and dkms is able to build modules for the just installed
kernel.

dkms will check that and break installation if this precondition is not
provided.  And no better solution is known to make sure we can build
those modules.

It however have nothing to do with vmlinux.h, which is not for kernel
modules.

Bastian

-- 
We have phasers, I vote we blast 'em!
		-- Bailey, "The Corbomite Maneuver", stardate 1514.2

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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
>
>

-- 
Colm Buckley | colm@tuatha.org

[toc] | [prev] | [next] | [standalone]

#82165 — Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Mon, 1 Apr 2024 22:35:09 +0200
with message-id <20240401203509.xkfcptlougyfss54@shell.thinkmo.de>
and subject line Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
has caused the Debian Bug report #1064976,
regarding linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#82443 — Bug#1064976: Sad user.

[Multipart message — attachments visible in raw view] — view raw

I see that this dependency is persisting in the new BPO release of
linux-headers 6.7.12, and it still causes significant trouble for me on my
build system.
I still can't understand what problem it's supposed to be fixing. Was there
ever an original bug report indicating the issue?

Colm

-- 
Colm Buckley | colm@tuatha.org

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.kernel

csiph-web