Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #82147 > unrolled thread
| Started by | Colm Buckley <colm@tuatha.org> |
|---|---|
| First post | 2024-04-06 09:50 +0200 |
| Last post | 2024-04-06 09:52 +0200 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.debian.kernel
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
| From | Colm Buckley <colm@tuatha.org> |
|---|---|
| Date | 2024-04-06 09:50 +0200 |
| Subject | Re: 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]
| From | Colm Buckley <colm@tuatha.org> |
|---|---|
| Date | 2024-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]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2024-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