Your message dated Mon, 1 Apr 2024 22:09:41 +0100
with message-id
<cakecruothj53rkpjcm3_4fmszxy74utosdes8mevaugpqqg...@mail.gmail.com>
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 ow...@bugs.debian.org
immediately.)
--
1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-headers-6.6.13+bpo-amd64
Severity: normal
X-Debbugs-Cc: c...@tuatha.org
Dear Maintainer,
The linux-headers packages for kernel version 6.6 seem to depend on the
corresponding
linux-image packages, but I believe that this should not be the case (and was
not the
case in previous versions). It should be possible to install the header files
for
a particular kernel version (eg: to allow for modules to be built for that
version,
which is my use case) without requiring the kernel image to be installed.
I think the headers packages should depend on a suitable version of
linux-kbuild and
any necessary glibc headers or other build artifacts, but not on linux-image-*
Many thanks,
Colm
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (900, 'stable-updates'), (900, 'stable-security'), (900, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages linux-headers-6.6.13+bpo-amd64 depends on:
ii gcc-12 12.2.0-14
pn linux-headers-6.6.13+bpo-common <none>
pn linux-image-6.6.13+bpo-amd64 | linux-image-6.6.13+bpo-amd64-unsi <none>
gned
pn linux-kbuild-6.6.13+bpo <none>
linux-headers-6.6.13+bpo-amd64 recommends no packages.
linux-headers-6.6.13+bpo-amd64 suggests no packages.
--- End Message ---
--- Begin Message ---
With respect; this is not resolved. I fundamentally disagree with your
assessment and with the approach of having a (largely) source package
depend on a binary package. The extreme edge case (building BPF modules)
should not dictate the general dependencies of the headers package; if
necessary we can add linux-build-bpf-6.6 and similar which includes all
necessary dependencies. There really has to be a way to install the headers
Colm
--
Colm Buckley | c...@tuatha.org
On Mon, 1 Apr 2024 at 22:05, Colm Buckley <c...@tuatha.org> wrote:
> Sure - have a separate package which depends on a given version of both
> (linux-complete-6.6.13-amd64?), but don't require the image to be installed
> if all one needs is the headers. Or have the headers package "recommend" or
> "suggest" the image package rather than depend on it.
>
> Consider, please, my use case - I can't imagine it's *that* unusual: I
> have a build server which builds a bunch of DKMS modules for
> numerous different kernel versions and architectures; at the moment it has
> eight different headers packages installed, and builds modules and packages
> them up into deb packages for each of these targets. If the image files for
> all of these are pulled in also, that will be about 1GB of additional
> churn, not to mention the additional work required to make sure my system
> doesn't accidentally *boot* from one of these superfluous kernels; if it
> boots from one of the -cloud-amd64 kernels for example, several important
> hardware drivers will be missing.
>
> There are plenty of cases where the header files for a specific kernel
> version might be needed but the image will be not merely useless, but
> actively harmful (eg: small partition for /boot).
>
> The xz debacle over the weekend should serve as a warning against
> overly-broad dependencies. Only depend on the things which the vast
> majority of your users will need; building BPF modules is, with respect, a
> severe edge case which should really be handled *specifically* rather than
> being the *default*.
>
> Colm
>
>
>
> On Mon, 1 Apr 2024 at 21:35, Bastian Blank <wa...@debian.org> wrote:
>
>> On Mon, Mar 04, 2024 at 09:51:56AM +0000, Colm Buckley wrote:
>> > As per the discussion in
>> > https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 - once
>> > vmlinux.h is included with linux-headers, the warning about cmd_btf_ko
>> etc.
>> > should be harmless, as that file should already be available (ie:
>> there's
>> > no need to generate it again as part of kernel build). Am I missing
>> > something else? I confess I have only a very small amount of experience
>> > with BPF code; I played with building a few modules, but I don't use it
>> > regularly.
>>
>> No. We need to make sure someone installing linux-image-bla and
>> linux-headers-bla have the same version, so the modules are compatible.
>>
>> vmlinux.h is not for modules.
>>
>> If you have a better idea how to solve this problem with kernel modules,
>> please speak up.
>>
>> Bastian
>>
>> --
>> It is undignified for a woman to play servant to a man who is not hers.
>> -- Spock, "Amok Time", stardate 3372.7
>>
>
>
> --
> Colm Buckley | c...@tuatha.org
>
>
--
Colm Buckley | c...@tuatha.org
--- End Message ---
