Different kernel-headers version

Hello,
the installed/available version of kernel-headers does not match the current kernel:

dnf list kernel.* kernel-devel* kernel-headers-*
Installed Packages
kernel.x86_64 5.3.7-301.fc31
kernel.x86_64 5.4.15-200.fc31
kernel-devel.x86_64 5.4.15-200.fc31
kernel-headers.x86_64 5.4.7-200.fc31
Is version 5.4.7-200 of kernel-headers identical to version 5.4.15-200?

1 Like

It’s not necessary to rebuild them everytime.
This recently came up on the kernel mailing list.

2 Likes

As it is shown in one of the Learn C++ (c) lessons (it isn’t exact copy; // means comments):

// something.cpp -- source file

// definitions (and declarations? I'm forget)
// void: function doesn't return anything to the caller
// a: name of the function
// (): function doesn't accept arguments == function has no parameters
void a()
{
        // call to b()
        b();
}

void b()
{
        // just to simplify
        a();
}

Trouble is: Compilers make their job line by line.  a() should know what b() is before calling it.  Same goes for b().  To not … play with all of such things (and place functions somewhere inside of sources “between this and that”), and to provide other advantages, the header files were invented:

// something.h -- header file

// Header guard. I'd forget how to do this.

// declarations (not definitions!)
// compiler will be unaware about the implementation,
// but it wll be aware of this functions "ins" and "outs"
void a();
void b();
// something.cpp -- sources file, again

/* use it as "forward declaration"
 * to make the compiler know what a(), b() and such is.
 */
#include "something.h"
...

Summary: If your’d modified a() or b()'s implementation, but neither their return types, nor their parameters, there is no need to update the header file.

// something.cpp -- again: source file

// update !
void a(char c, int d)
{
        b();
}

// no update...
void b()
{
        a();
        a();
}

PS:  Linux written in C, not in C++.

@geowyze

Gentoo Wiki: Linux Headers (FAQ).  A little bit “friendlier” answer :smirk_cat:.

Thank you for the information.

In my opinion this isn’t a good a solution because matching version numbers would allow to easily verify matching packages and also allows to use $(uname -r). Oracle Virtualbox, nvidia, and I guess other sources suggest to verify/use this:

Note
The running kernel and the kernel header files must be updated to matching versions.

https://www.virtualbox.org/manual/UserManual.html#install-linux-host

Fedora
The kernel headers and development packages for the currently running kernel can be installed with:
sudo dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r)

1 Like

Why?

And the people would need to guess in which versions of the Kernel the changes to headers were maded?

Last changes were maded in 5.4.7, so i know think that the developers’ work was a maintenance work up to the (at least) 5.4.15 Kernel.  Adding anything new, or changing existing things would require the developers to update the headers.

I think I pointed out why. And I think that for the majority it is confusing and not relevant to know when changes have been made. This information is relevant for developers.
BTW, your link to GenToo was not helpful as it states that headers can be newer.
Anyways, I do not want to start a basic disussion about this and I accepted the answer.

Last one from me, please:

kernel-header-1.1
a b c

kernel-header-1.2
a b c

kh-1.1 == kh-1.2

→ 5.4.7 isn’t older than 5.4.15!

PS:

And for the people with a “tricky” hardwares!

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.