Kernel Version naming

tleydxdy · 2017-10-11 05:46:48

I was fixing an AUR package that was broken. nct6775-git
the problem is that the kernel version in /usr/lib/modules is not consistent, especially, the kernel version in extramodules-* is different from the result of uname -r.

e.g.

$ ls /usr/lib/modules
4.13.4-1-ARCH  extramodules-4.13-ARCH

Last edited by tleydxdy (2017-10-11 05:48:34)

Scimmia · 2017-10-11 05:48:21

And what, specifically, is wrong with that? Looks totally normal to me.

tleydxdy · 2017-10-11 05:50:02

Scimmia wrote:

And what, specifically, is wrong with that? Looks totally normal to me.

so I'm wondering how to get 4.13-ARCH style naming within PKGBUILD

for example:

If I want to go to

/usr/lib/modules/4.13.4-1-ARCH

I would use

$ cd /usr/lib/modules/$(uname -r)

how do I go to

/usr/lib/modules/extramodules-4.13-ARCH

like that?

Last edited by tleydxdy (2017-10-11 05:57:18)

seth · 2017-10-11 08:49:18

prepend "extramodules-" and strip the release and build part from the version??

Allan · 2017-10-11 09:07:16

I feel like the real question is not being asked...

loqs · 2017-10-11 11:30:54

$ ls -lad "/usr/lib/modules/$(uname -r)/extramodules"

but what is wrong with the solution you are currently using https://aur.archlinux.org/cgit/aur.git/ … d2452af5bd

progandy · 2017-10-11 12:05:58

loqs wrote:

$ ls -lad "/usr/lib/modules/$(uname -r)/extramodules"
but what is wrong with the solution you are currently using https://aur.archlinux.org/cgit/aur.git/ … d2452af5bd

Readlink should be better than ls if it has to be automatic instead of the extramodules variable.

readlink -f "/usr/lib/modules/$(uname -r)/extramodules"

seth · 2017-10-11 14:09:59

Looking into the AUR comments, he likely wants a more dynamic code in PKGBUILD.

@tleydxdy
The plain solution is to use /lib/modules/`uname -r`/extramodules/ as installation path, BUT this assumes the running kernel is the desired kernel to build this on what will fail if the user just upated (eg. 4.13 -> 4.14) or has several kernels around (eg. the lts variant)
For the former case you'd have to check the version of the installed linux package and for the former you got to actually ask what kernel to build this on.

loqs · 2017-10-11 16:20:02

One issue with https://aur.archlinux.org/cgit/aur.git/ … d2452af5bd the install file was not updated for the extramodules path change.

progandy · 2017-10-11 18:23:29

The official nvidia package also uses the hardcoded _extramodules variable, the same as your nct6775.
https://git.archlinux.org/svntogit/pack … ges/nvidia

Maybe using dkms would be a better alternative for you if the kernel version should be dynamic?

Edit: Improved wording.

Last edited by progandy (2017-10-11 18:45:16)

seth · 2017-10-11 18:33:27

That var is simply hardcoded on the top of the file.

eschwartz · 2017-10-11 22:01:28

You can get the correct version by manipulating the output of `pacman -Q linux`.

If this package is built against "whatever the currently running kernel is", it is *wrong*. You should create an additional -lts or -hardened or -zen or -ck or whatever package, or just do the reasonable thing and migrate to a -dkms package.

There isn't a ton of usefulness in non-dkms packages when you aren't providing built packages in a custom repository.

Arch Linux

#1 2017-10-11 05:46:48

Kernel Version naming

#2 2017-10-11 05:48:21

Re: Kernel Version naming

#3 2017-10-11 05:50:02

Re: Kernel Version naming

#4 2017-10-11 08:49:18

Re: Kernel Version naming

#5 2017-10-11 09:07:16

Re: Kernel Version naming

#6 2017-10-11 11:30:54

Re: Kernel Version naming

#7 2017-10-11 12:05:58

Re: Kernel Version naming

#8 2017-10-11 14:09:59

Re: Kernel Version naming

#9 2017-10-11 16:20:02

Re: Kernel Version naming

#10 2017-10-11 18:23:29

Re: Kernel Version naming

#11 2017-10-11 18:33:27

Re: Kernel Version naming

#12 2017-10-11 22:01:28

Re: Kernel Version naming

Board footer