XPost: linux.debian.bugs.dist
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
<div dir="ltr">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.<div><br></div><div>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.</
<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:57, Colm Buckley <<a
href="mailto:
colm@tuatha.org">
colm@tuatha.org</a>> 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"><div dir="ltr">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.<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 "apt install linux-image-Y" - 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 "
Suggests" from each, and maybe even in DKMS?</div><div><br></div><div><blockquote style="margin:0px 0px 0px 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 <<a href="mailto:
waldi@debian.org" target="_blank">
waldi@debian.org</a>> 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> > ... but the proposed dependency wouldn'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, "The City On the Edge of Forever",<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>
</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)