[SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

kauron · 2026-05-13 09:33:33

Hi, I'm trying to avoid having the zfs-dkms module and my kernel reach incompatible version (e.g., zfs 2.4.1 is compatible with linux up to 6.19, so if I update linux to >6.19, I'll need to update zfs to 2.4.2, compatible with linux up to 7.0, or not upgrade the kernel until I can upgrade zfs).

I was trying to use pacman dependency checking to avoid this bad situation, but I can't find a way to select a kernel version without selecting a specific kernel. I am editing zfs-dkms's PKGBUILD (https://aur.archlinux.org/cgit/aur.git/ … h=zfs-dkms) with:

package() {
   depends=(... 'linux>=4.18' 'linux<7.1')

But that means that it depends specifically on linux, and I cannot satisfy this dependency with linux-lts, even if the versions match. I tried looking for virtual packages provided by all kernels, but I can find none. The -headers packages for both kernels do provide LINUX-HEADERS, but do not specify a version, so I cannot write `'LINUX-HEADERS>=4.18' 'LINUX-HEADERS<7.1'` in the depends field.

Is it possible to use pacman's dependency resolution and `depends` to solve this problem? Or would it require the kernel packaging to include a version in the provides LINUX-HEADERS? Just curious, I know there are other alternatives, such as a pre-hook that checks versions and fails or just adding the kernel package to IgnorePkg in pacman.conf.

For reference, here are the provides for linux, linux-lts, linux-headers, linux-lts-headers (none specify a version, contrary to this note in the ArchWiki https://wiki.archlinux.org/title/PKGBUILD#provides).

Name            : linux
Version         : 7.0.5.arch1-1
Provides        : KSMBD-MODULE  NTSYNC-MODULE  VIRTUALBOX-GUEST-MODULES  WIREGUARD-MODULE
Name            : linux-lts
Version         : 6.18.28-1
Provides        : KSMBD-MODULE  VIRTUALBOX-GUEST-MODULES  WIREGUARD-MODULE
Name            : linux-headers
Version         : 7.0.5.arch1-1
Provides        : LINUX-HEADERS
Name            : linux-lts-headers
Version         : 6.18.28-1
Provides        : LINUX-HEADERS

Last edited by kauron (2026-05-15 19:40:25)

cryptearth · 2026-05-13 11:38:28

zfs 2.4.2 was released about 12h ago
the archzfs project lacks a bit behind because we want to implement a new automation
in the mean time you can either build from source yourself or use my fork: https://github.com/n0xena/archzfs/releases/tag/2.4.2
i also hace linked a completed test suite - the migration failure is known and a test environment issue - so nothing that shiuld stop you
btw: why do you use dkms in the first place? do you run a custom kernel? if so just fork archzfs for your kernel
if you use one of tge standard kernels: why do you use dkms then? use prebuilt and tested builds

if you RELY on both zfs and latest kernel: use LTS

Last edited by cryptearth (2026-05-13 11:39:43)

kauron · 2026-05-14 05:20:07

Thanks for the response, cryptearth, but I'm using zfs as an example, my question is about packaging. I was actually prompted by the release of 2.4.2 to try and find a system that would stop me from upgrading to an incompatible kernel. I am using linux-lts to avoid falling outside the compatibility of zfs, and dkms so that I do not need to rebuild packages manually (I am not using an AUR helper), I only need to update zfs when upstream updates, and not on every kernel update.

The question is: what can I write in a PKGBUILD for a package I control to check for a specific version (or range of versions) of the linux kernel? Can I use an OR in depends?

I do not want to write:

depends=('linux-lts>=4.1' 'linux-lts<7.1')

Because then I'm tied to a specific kernel, and cannot switch to `linux` or any other variant. Really, it is just a curiosity, I know there are other ways to handle zfs, as listed on the wiki.

Last edited by kauron (2026-05-14 05:20:26)

seth · 2026-05-14 08:21:29

Since the depends arrays encode AND you'd want to use "conflicts" as OR list

conflicts=('linux-lts<=4.1' 'linux-lts>7.1' 'linux<=4.18' 'linux>7.1')

cryptearth · 2026-05-14 09:29:01

you can avoid both dkms and aur by either just download the package or add archzfs as repo https://github.com/archzfs/archzfs/rele … perimental
dkms is really only required if you don't use any of the 4 repo kernels
as for lts to not fall out of supported by zfs: that's also the target of archzfs: try to keep up with upstream but focus on lts - that's why only full releases are supported but not -rc or -git

dkms is pretty much just building yourself but instead of makepkg which would respect contraints in pkgbuild it's a local
autoconf
configure
make
make install
or to put it this way: at least with zfs and dkms you do it wrong - because the internals of zfs build rely on the META file which sets which kernels are suppported (which in 2.4.2 has a bug and was set to 99.99)
you now want to mimic this back in the pkgbuild for dkms - solution: then don't use dkms but the prebuilt packages from archzfs

i highly suspect your actual packages (as zfs was an example) cause you problems because thier build logic don't have an inner safeguard and just build against unsupported kernels - that's the issue with using dkms - and fix is either don't use dkms or implement a safeguard like zfs to check the supported kernel version during build

we could help you better if you don't hide your question behind "using zfs as example" but the actual packages that cause yiu issues

Last edited by cryptearth (2026-05-14 09:29:27)

kauron · 2026-05-15 19:39:43

So "conflicts" does work as an OR list, thank you seth.

Regarding zfs and using dkms vs external repositories/externally built packages, it's something I'm currently considering. Perhaps I was weighing archzfs too negatively due to its unofficial status.

I'm marking this thread as solved, I have two options to solve this problem.

cryptearth · 2026-05-17 02:31:07

well, zfs can't become "official" due to its history and license: it's incompatible with the one the linux kernel is distributed with and hence denies distributing it along
so for any distro that respects this (unlike canonical) unless its license is changed to one compatible with the linux kernel it will never be part of any official distro repo but always has to be provided external

aur vs archzfs-repo: although i'm only a contributor to the archzfs project and not a member of its group i followed its developement quite close since i moved to arch in late 2022
the gist is: after its head maintainer struggled with time a group formed to relief them and get the project a new push - since it was moved from an external server to github both for building and as repo
currently additional integration is worked such as auto-push on new zfs version instead of current manual PR

what the aur is up to: i don't know as i don't follow its actions - but by a quick look it lists several different maintainers for the different packages

why i maintain my fork: after the archzfs got a new push i could shutdown my fork - but i keep it up as archzfs focus on lts - while i use mainline/zen - and at least by the insights github provides me there're downloads from others - so it seems at least someone trusts me and relies on it (although i have a disclaimer refering to archzfs)
I also currently work on a CI environment for upstream zfs so they can have an arch test runner which they currently lack
i also do full runs of the test suite (about 4hours each) and provide it back to archzfs and upstream zfs - that's my way of supporting the zfs community - as FOSS doesn't mean free as in "it doesn't cost money" - that's just a side effect of people like investing thier own time (and sometimes money) to provide the community free of charge

Arch Linux

#1 2026-05-13 09:33:33

[SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

#2 2026-05-13 11:38:28

Re: [SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

#3 2026-05-14 05:20:07

Re: [SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

#4 2026-05-14 08:21:29

Re: [SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

#5 2026-05-14 09:29:01

Re: [SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

#6 2026-05-15 19:39:43

Re: [SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

#7 2026-05-17 02:31:07

Re: [SOLVED] DKMS, select compatible kernel versions w/ PKGBUILD depends?

Board footer