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

<div dir="ltr">Bastian wrote:<div>&gt; Luca wrote:</div><div>&gt;&gt; Let&#39;s look at this the other way around: if there was no dependency, in<br>&gt;&gt; what scenario would things break and how?<br><br>&gt; - linux-headers-bla and linux-image-bla
are installed<br>&gt; - linux-image-bla is uipgraded<br>&gt; - no modules will be built, because the matching headers are missing<br><div><br></div><div>... but the proposed dependency wouldn&#39;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 (<a href="https://lists.debian.org/debian-kernel/2024/04/msg00024.html">https://lists.debian.
org/debian-kernel/2024/04/msg00024.html</a>), 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 &quot;linux-complete&quot; package which depends on both (and could
be Suggests: by both). Users who need to keep -image and -headers in sync could install this.</div><div><br></div></div><div>Thank you for taking the time to explain the problem; the earlier parts of this thread were very confusing to me.</div><div><br></

<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>Colm</div></div><div><br></div></blockquote><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div

dir="ltr"><div><div dir="ltr"><span style="color:rgb(153,153,153);font-size:x-small">Colm Buckley | </span><a href="mailto:colm@tuatha.org" style="font-size:x-small" target="_blank">colm@tuatha.org</a><div><br></div></div></div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

<div dir="ltr">Please explain. I am really sorry to be dragging this discussion out, but I honestly think there is some information I&#39;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.<div><br></div><div>Your proposal is to have linux-headers-X depend on linux-image-X.</div><div><br></div><div>But:</div><div><br></div><div>* User installs linux-image-X and linux-
headers-X</div><div>* User builds modules for this image using DKMS or whatever</div><div>* User then does &quot;apt install linux-image-Y&quot; - this is the exact scenario you hope to guard against?</div><div>... nothing brings in linux-headers-Y; the
user is *still* left without their new modules.</div><div><br></div><div>Your proposal will only work if the user remembers to upgrade -headers... which will fix the problem even without the dependency!</div><div><br></div><div>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 &quot;Suggests&quot; from each, and maybe even in DKMS?</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>Colm</div><div><br></div></blockquote></div></div><br><
div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 2 Apr 2024 at 17:51, Bastian Blank &lt;<a href="mailto:waldi@debian.org">waldi@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-
left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote:<br>
&gt; ... but the proposed dependency wouldn&#39;t address that, right?<br>

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

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

Bastian<br>

-- <br>
Prepare for tomorrow -- get ready.<br>
                -- Edith Keeler, &quot;The City On the Edge of Forever&quot;,<br>
                   stardate unknown<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(153,153,153);font-size:x-small">Colm Buckley | </span><
a href="mailto:colm@tuatha.org" style="font-size:x-small" target="_blank">colm@tuatha.org</a><div><br></div></div></div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)