Bug#1064976: Sad user.
I see that this dependency is persisting in the new BPO release of linux-headers 6.7.12, and it still causes significant trouble for me on my build system. I still can't understand what problem it's supposed to be fixing. Was there ever an original bug report indicating the issue? Colm -- Colm Buckley | c...@tuatha.org
Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
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 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 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 | c...@tuatha.org > > -- Colm Buckley | c...@tuatha.org
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, 2 Apr 2024 at 16:52, Bastian Blank wrote: > > On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi 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 Got it, thanks, that makes sense to me as a problem and it would be good to solve. Is the root cause that the image and the headers package are published and uploaded separately, due to signing?
Bug#1064976: Having headers depend on image - bad idea I think
Hi On Tue, Apr 02, 2024 at 03:26:32PM +, Colm Buckley wrote: > This is a real problem - however I think it is *not* one which the change > in dependency addresses; even if -headers-Y depends on -image-Y, step 3 > above will proceed without any conflicts (because the reverse dependency is > not true). I think the only realistic way to address this (assuming we > don't want to make -image depend on -headers) would be to have a > linux-complete (not sold on the name) package series which depends on > corresponding versions of both image and headers packages. Users who > regularly build new modules should be encouraged to install this package > and have it pull in suitable versions of both headers and image. No, there is no "correct" solution. Anything correct would need not only moving the dependencies, but also the maintainer scripts, into one package. This is not going to be done without major restructuring. So as long as there is no concept and support for that it will remain a somewhat working solution. Regards, Bastian -- Change is the essential process of all existence. -- Spock, "Let That Be Your Last Battlefield", stardate 5730.2
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi 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 Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7
Bug#1064976: Having headers depend on image - bad idea I think
I wrote: [...] From the maintainer's most recent comments, I believe that the > problem is something like: > > * user has installed linux-headers and linux-image for kernel version X > * user has built additional modules using DKMS which are installed into > the running system > * user upgrades linux-headers to version Y, new modules get rebuilt > * user does not upgrade linux-image from X to Y, confusion results > > Having linux-image-Y be a dependency of linux-headers-Y does indeed > address this problem, but [...] > The most recent comment ( https://lists.debian.org/debian-kernel/2024/04/msg00020.html) from the maintainer indicates that he has a slightly different problem in mind: * user has installed linux-headers and linux-image for version X * user has built additional modules using DKMS, installed into the running system * user upgrades the *kernel image* to version Y but forgets to upgrade the headers * as a result, new kernel is missing important modules, confusion reigns This is a real problem - however I think it is *not* one which the change in dependency addresses; even if -headers-Y depends on -image-Y, step 3 above will proceed without any conflicts (because the reverse dependency is not true). I think the only realistic way to address this (assuming we don't want to make -image depend on -headers) would be to have a linux-complete (not sold on the name) package series which depends on corresponding versions of both image and headers packages. Users who regularly build new modules should be encouraged to install this package and have it pull in suitable versions of both headers and image. Is this correct, Bastian? I'm sorry for taking so long to understand what problem was being addressed here. Colm -- Colm Buckley | c...@tuatha.org
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, 2 Apr 2024 08:27:39 +0200 Bastian Blank wrote: > On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote: > > Why do dkms modules need the image installed to be built? At the very > > least they didn't use to, the headers were enough last time I had to > > deal with that stuff for the nvidia drivers > > dkms is used to build modules for the kernel that is just being > installed. To do that it needs also the headers in matching versions. > > As the image can't depend on the headers, some other way was needed. Sorry, I am still unable to understand the issue: dkms can and does build modules for all installed _headers_ (plural). The fact that the headers pull in a corresponding image does not change that fact, as far as I can tell. In fact, it doesn't need any images at all, again as far as I know. Let's look at this the other way around: if there was no dependency, in what scenario would things break and how? -- Kind regards, Luca Boccassi
Bug#1064976: Having headers depend on image - bad idea I think
Control: reopen 1064976 My apologies for the ping-pong; I do want to keep this open until the discussion has completed. I will set out my thoughts below. I'm afraid this is fairly long. A brief history of this issue: in December 2023, the control file for linux-headers-* was altered to include a dependency on linux-image-* ( https://salsa.debian.org/kernel-team/linux/-/merge_requests/903). As far as I can tell, no bugreport was linked as a problem being addressed with this change; the maintainer's comment was "A lot of problems arise if users use headers of a different version then the associated image. The easiest solution is to make them depend." Note that this dependency did not exist in any previous version of linux-headers as far as I can determine; the problems seem to be largely theoretical. This change worked its way through the release pipeline and eventually arrived in bookworm-backports around the end of February 2024, with the promotion of the package linux-headers-6.6.13+bpo-amd64 (and others) to backports. I immediately noticed the impact on my build server, and submitted a bug report ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976) requesting that it be reverted. The maintainer defended the change, indicating that it was necessary for people using dkms; when pressed on exactly what failed, he mentioned the BTF warnings [1] but as far as I can tell, no specific user problem was presented. Several attempts by myself and Luca Boccassi to determine what problem was being addressed were not answered. The bug was closed as WONTFIX a few days ago, but still there has been no real explanation as to why the change was introduced in the first place. I would like to go on the record here as saying (especially with the xz-utils exploit still in everyone's memory), that we should be *extremely careful* with changing things like dependency trees without very well-documented reasons, *especially* for something as critical as the kernel packages. I ordinarily try to be very respectful of maintainers' latitude and discretion in packaging decisions, but here I am trying to ensure that a serious problem is addressed in BPO before it gets promoted to stable. The change is significant enough that I feel it deserves more discussion and attention than it has so far received. Having re-read the thread a few times today, I feel that the BTF warnings (which were originally presented as the main reason for this change) are a red herring and not relevant. The new packaging of vmlinux.h does address the issue of BPF builds for pretty much all users (it's true that build pipelines will have to be adjusted, but the new system is a significant improvement on the old). The discussion about BPF kernel modules does not seem to be based on any real user activity, and to be honest it seems somewhat self-contradictory - why would a kernel module need BPF in the first place? Let's consider the possible reasons for having the header package depend on the image package: >From Debian's policy documentation; "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." So what functionality is provided by linux-headers-*? I would posit initially that their main function is unspecified apart from "having the header files for the specific kernel exist under /usr/src", which clearly does not require the image package. However, a major use case for the header files is to build kernel modules, whether using DKMS or some other mechanism. But this use case *also* does not require the image package; in fact this is the main reason the header files were packaged as they are. Hundreds of thousands (at least) of Debian users have been happily building kernel modules using linux-headers packages without the corresponding image files for decades, and there are no recent kernel changes which break this ability. The recent introduction of vmlinux.h additionally addresses an edge case (building BPF programs) which formerly *did* require a built image for its symbol table. So the important piece of functionality also does not require the kernel image package. Now, given the maintainer's comments on the original PR and in this bug, I suspect I understand the real reason for the change: in order to *run* modules built using DKMS etc., obviously the corresponding kernel image file needs to be present. From the maintainer's most recent comments, I believe that the problem is something like: * user has installed linux-headers and linux-image for kernel version X * user has built additional modules using DKMS which are installed into the running system * user upgrades linux-headers to version Y, new modules get rebuilt * user does not upgrade linux-image from X to Y, confusion results Having linux-image-Y be a dependency of linux-headers-Y does indeed address this problem, but I feel that it is fairly substa
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote: > Why do dkms modules need the image installed to be built? At the very > least they didn't use to, the headers were enough last time I had to > deal with that stuff for the nvidia drivers dkms is used to build modules for the kernel that is just being installed. To do that it needs also the headers in matching versions. As the image can't depend on the headers, some other way was needed. Bastian -- Spock: We suffered 23 casualties in that attack, Captain.
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 1 Apr 2024 at 21:49, Bastian Blank wrote: > > Control: tags -1 wontfix > > On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote: > > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > > With the new vmlinux.h shipped in the headers package, the BTF case > > > should be covered. > > As said, this dependency is to make sure kernel modules are properly > built. vmlinux.h is not for kernel modules. Why do dkms modules need the image installed to be built? At the very least they didn't use to, the headers were enough last time I had to deal with that stuff for the nvidia drivers
Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package)
On Mon, Apr 01, 2024 at 08:39:06PM +, Debian Bug Tracking System wrote: > No. We need to make sure someone installing linux-image-bla and > linux-headers-bla have the same version, so the modules are compatible. Revisiting this bug, I might have been not explicit enough. This dependency is needed, so headers and kernel will be available in the same version and dkms is able to build modules for the just installed kernel. dkms will check that and break installation if this precondition is not provided. And no better solution is known to make sure we can build those modules. It however have nothing to do with vmlinux.h, which is not for kernel modules. Bastian -- We have phasers, I vote we blast 'em! -- Bailey, "The Corbomite Maneuver", stardate 1514.2
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Control: tags -1 wontfix On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote: > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > With the new vmlinux.h shipped in the headers package, the BTF case > > should be covered. As said, this dependency is to make sure kernel modules are properly built. vmlinux.h is not for kernel modules. Bastian -- Mind your own business, Spock. I'm sick of your halfbreed interference.
Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*
Control: tags -1 patch On Tue, 19 Mar 2024 12:32:16 + Colm Buckley wrote: > Package: linux-headers-amd64 > Version: 6.6.13-1~bpo12+1 > Followup-For: Bug #1064976 > X-Debbugs-Cc: c...@tuatha.org > > Can I suggest in the interim that Depends: be replaced with Recommends: > or Suggests: given that most installations won't actually need the image > package? MR to downgrade to recommends: https://salsa.debian.org/kernel-team/linux/-/merge_requests/1054 -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*
Package: linux-headers-amd64 Version: 6.6.13-1~bpo12+1 Followup-For: Bug #1064976 X-Debbugs-Cc: c...@tuatha.org Can I suggest in the interim that Depends: be replaced with Recommends: or Suggests: given that most installations won't actually need the image package? Colm
Bug#1064976:
Hey folks - I see that linux-headers-* has been promoted to 6.6 in the BPO channel, but this dependency is still in place. Is it really the case that we want to drag in the image binaries and other machinery as a dependency for a source package like linux-headers. I feel that the BPF use case should really be addressed using vmlinux.h (the "skipping BTF generation" message should be ignored as all of this information *should* be included in vmlinux.h). Any further thoughts? Colm
Bug#1064976:
I am assuming that the original intent of adding linux-image-* as a dependency was to prevent the "Skipping BTF generation for %s due to unavailability of vmlinux" warning from being printed; is that a fair assumption? I am quite sure that this will not cause problems because of the decision in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 to include vmlinux.h in the headers package. This file is the thing which is generated by "cmd_btf_ko" in the upstream kernel build, so any module or userspace program which depends on BPF will be able to pull the necessary information from that file. As Luca says, adding the image and associated machinery as a dependency to a source file is a very heavy-handed way to solve quite a niche problem (which I don't think even is a problem). It makes assumptions which I don't think hold true in many cases; especially that the system being used to build a kernel or kernel module is the same as the system which will be running it (or even have the same CPU architecture). Any DKMS or other out of tree packages which require the Linux image to be installed should declare that dependency themselves; I am pretty sure that declaring it here is not the right thing. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 4 Mar 2024 13:54:49 +0100 Bastian Blank wrote: > On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote: > > > But we where talking about kernel modules. > > There are kernel modules using BPF stuff? Never seen one, do you have > > an example? > > No idea, but they get linked BTF information, so you could use them. Sure, but it's a bit of an unusual case to say the least, and I'm not aware of dkms packages in Debian doing that (happy to stand corrected if that's not the case). So surely any out-of-distro dkms package doing that should just ensure they pull in the dependencies they need for it? Assuming it's even needed. As far as I understand, the point of vmlinux.h is that it gives the equivalent information generated from BTF. The issue is that pulling the headers package also pulls the image, initramfs and all that machinery. We are going to depend on the headers package in src:systemd from the next release to get the vmlinux.h, and pulling all that stuff too adds considerable weight to the build dependency installation job. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote: > > But we where talking about kernel modules. > There are kernel modules using BPF stuff? Never seen one, do you have > an example? No idea, but they get linked BTF information, so you could use them. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 4 Mar 2024 at 10:32, Bastian Blank wrote: > > On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote: > > Yes precisely, the bpf program source can just include vmlinux.h and it > > should build and run as expected. > > But we where talking about kernel modules. > > Bastian There are kernel modules using BPF stuff? Never seen one, do you have an example?
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote: > Yes precisely, the bpf program source can just include vmlinux.h and it > should build and run as expected. But we where talking about kernel modules. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
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. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 14:23:05 + Colm Buckley wrote: > On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > > With the new vmlinux.h shipped in the headers package, the BTF case > > > should be covered. > > > > The relevant code in Linux is: > > > > | quiet_cmd_btf_ko = BTF [M] $@ > > | cmd_btf_ko = > \ > > | if [ ! -f vmlinux ]; then > \ > > | printf "Skipping BTF generation for %s due to > unavailability of vmlinux\n" $@ 1>&2; \ > > | else > \ > > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) > --btf_base vmlinux $@; \ > > | $(RESOLVE_BTFIDS) -b vmlinux $@; > \ > > | fi; > > > > Which change is needed here to use vmlinux.h instead? > > My understanding is that you don't need this command at all; the included > vmlinux.h already contains the necessary type definitions for libbpf, for > the kernel source version in question - ie: instead of needing to run > pahole or bpftool to extract these definitions from a specific vmlinux > image, this file is distributed with them already included. Yes precisely, the bpf program source can just include vmlinux.h and it should build and run as expected. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > With the new vmlinux.h shipped in the headers package, the BTF case > > should be covered. > > The relevant code in Linux is: > > | quiet_cmd_btf_ko = BTF [M] $@ > | cmd_btf_ko = \ > | if [ ! -f vmlinux ]; then \ > | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ > | else \ > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ > | $(RESOLVE_BTFIDS) -b vmlinux $@; \ > | fi; > > Which change is needed here to use vmlinux.h instead? My understanding is that you don't need this command at all; the included vmlinux.h already contains the necessary type definitions for libbpf, for the kernel source version in question - ie: instead of needing to run pahole or bpftool to extract these definitions from a specific vmlinux image, this file is distributed with them already included. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > With the new vmlinux.h shipped in the headers package, the BTF case > should be covered. The relevant code in Linux is: | quiet_cmd_btf_ko = BTF [M] $@ | cmd_btf_ko = \ | if [ ! -f vmlinux ]; then \ | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ | else\ | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ | $(RESOLVE_BTFIDS) -b vmlinux $@;\ | fi; Which change is needed here to use vmlinux.h instead? Bastian -- Bones: "The man's DEAD, Jim!"
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 12:25:27 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > > Why was this never the case before? And can you be more precise about what > > "stuff" is missing? Is there a previous bug report I can reference? > > It complains loudly about BTF. With the new vmlinux.h shipped in the headers package, the BTF case should be covered. I think we should nudge packages to use that, rather than looking at the kernel image, or worse sysfs from the running kernel, which is completely wrong for obvious reasons. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
> The build wants the image available (it does not really fail without, but lacks stuff) and we need some dependency to keep image and headers in sync for people using dkms. To be honest, "it does not really fail without, but lacks stuff" seems like the use case that "Recommends:" (or even "Suggests:") was designed for, rather than "Depends:", don't you agree? I'm not sure, of course, what problem is being addressed here; it's possible that there's a more elegant solution available. Is there a previous bug describing the problem? My concern is that I have a specific build server which builds kernels and modules for other machines in a farm. It needs to have the header files for specific target kernel versions installed, but it is not sensible to have the corresponding image packages installed (in many cases, those images wouldn't even run on this build server). Colm On Thu 29 Feb 2024, 11:03 Colm Buckley, wrote: > Why was this never the case before? And can you be more precise about what > "stuff" is missing? Is there a previous bug report I can reference? > > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. > > Colm > > > On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > >> Control: tags -1 wontfix >> >> On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: >> > 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. The build wants the image available (it does not really fail >> without, but lacks stuff) and we need some dependency to keep image and >> headers in sync for people using dkms. >> >> Bastian >> >> -- >> Vulcans never bluff. >> -- Spock, "The Doomsday Machine", stardate 4202.1 >> >
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > Why was this never the case before? And can you be more precise about what > "stuff" is missing? Is there a previous bug report I can reference? It complains loudly about BTF. > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. Sure, but installing the image does not break much. But not installing the headers breaks much. Maybe you can provide a proposal how that would work? Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Why was this never the case before? And can you be more precise about what "stuff" is missing? Is there a previous bug report I can reference? DKMS should handle its own dependencies, I'd have thought - I see a clear use case for installing header files without the corresponding images. Colm On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > Control: tags -1 wontfix > > On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > > 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. The build wants the image available (it does not really fail > without, but lacks stuff) and we need some dependency to keep image and > headers in sync for people using dkms. > > Bastian > > -- > Vulcans never bluff. > -- Spock, "The Doomsday Machine", stardate 4202.1 >
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Control: tags -1 wontfix On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > 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. The build wants the image available (it does not really fail without, but lacks stuff) and we need some dependency to keep image and headers in sync for people using dkms. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Some previous versions, for contrast: % apt-cache depends linux-headers-6.5.0-0.deb12.4-amd64 linux-headers-6.5.0-0.deb12.4-amd64 Depends: linux-headers-6.5.0-0.deb12.4-common Depends: linux-kbuild-6.5.0-0.deb12.4 Depends: linux-compiler-gcc-12-x86 % apt-cache depends linux-headers-6.1.0-18-amd64 linux-headers-6.1.0-18-amd64 Depends: linux-headers-6.1.0-18-common Depends: linux-kbuild-6.1 Depends: linux-compiler-gcc-12-x86
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
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-1212.2.0-14 pn linux-headers-6.6.13+bpo-common pn linux-image-6.6.13+bpo-amd64 | linux-image-6.6.13+bpo-amd64-unsi gned pn linux-kbuild-6.6.13+bpo linux-headers-6.6.13+bpo-amd64 recommends no packages. linux-headers-6.6.13+bpo-amd64 suggests no packages.
