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


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

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

Started byColm Buckley <colm@tuatha.org>
First post2024-04-06 09:50 +0200
Last post2024-04-06 09:52 +0200
Articles 3 — 2 participants

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


Contents

  Re: 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:50 +0200
    Re: 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
    Re: 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

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

FromColm Buckley <colm@tuatha.org>
Date2024-04-06 09:50 +0200
SubjectRe: Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Message-ID<Iq8Yu-4oGU-659@gated-at.bofh.it>

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

Bastian wrote:
> Luca 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

... but the proposed dependency wouldn't address that, right?
linux-headers-bla would keep linux-image-bla around, but if the user then
installed linux-image-newbla, then nothing would be pulling in the
corresponding headers. As I said in the other message (
https://lists.debian.org/debian-kernel/2024/04/msg00024.html), the only
ways to address this would be to have -image depend on -headers (I think
this is a bad idea, as do you), or to have a higher-order "linux-complete"
package which depends on both (and could be Suggests: by both). Users who
need to keep -image and -headers in sync could install this.

Thank you for taking the time to explain the problem; the earlier parts of
this thread were very confusing to me.

Colm

-- 
Colm Buckley | colm@tuatha.org

[toc] | [next] | [standalone]


#82166

FromColm Buckley <colm@tuatha.org>
Date2024-04-06 09:51 +0200
Message-ID<Iq8Yu-4oGU-663@gated-at.bofh.it>
In reply to#82147

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

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

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


#82176

FromBastian Blank <waldi@debian.org>
Date2024-04-06 09:52 +0200
Message-ID<Iq8Yu-4oGU-661@gated-at.bofh.it>
In reply to#82147
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

[toc] | [prev] | [standalone]


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


csiph-web