[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package)

Your message dated Mon, 1 Apr 2024 22:09:41 +0100
with message-id <CAKECruOthj53RkpJcm3_4fMszXy74utosdES8mEVAUgpQQgF6A@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 owner@bugs.debian.org
immediately.)


-- 
1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-headers-6.6.13+bpo-amd64
Severity: normal
X-Debbugs-Cc: colm@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 | colm@tuatha.org


On Mon, 1 Apr 2024 at 22:05, Colm Buckley <colm@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 <waldi@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 | colm@tuatha.org



--
Colm Buckley | colm@tuatha.org


--- End Message ---
Reply to: