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

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, <colm@tuatha.org> 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, <waldi@debian.org> wrote:
Control: tags -1 wontfix

On Wed, Feb 28, 2024 at 05:19:39PM +0000, 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

Reply to: