Stop handling dkms.conf as a bash/shell script about dkms HOT 8 OPEN

Aside: some packages seem somewhat borked (acpi-call, bbswitch, etc) aka PACKAGE_VERSION="#MODULE_VERSION#". Not sure if an Arch issue or upstream - will check as well.

That sounds like a Debian thing ;-) That placeholder is substituted by dh_dkms at package build time while generating/installing dkms.conf into the package.

from dkms.

Sorry for the late reply, got busy at work.

It's fine for me but I think it's a bit risky. I believe ZFS will not be the only case where copious amounts of bash scripts end up in the DKMS configuration file. For those cases, we would need to constantly extend to meet their demand where it makes sense, or they will keep on rolling out their own DKMS along with the rest, like AMD was doing.

from dkms.

No need to apologise - IRL get in the way.

I think it's beneficial to first get some rough numbers and if the number are favourable work from there. I've done a list for Arch below - @scaronni if you can do one (as time permits) for distros you care about that'll be appreciated.

Let me start with Arch proper, only. The AUR (user repos) have 400 of varying quality.

• acpi_call - affected, fixable (MAKE[0]="make KVER=$kernelver)
• bbswitch - similar to acpi_call
• broadcom-wl - not affected , ships with dozen+ patches
• deepin-anything - affected, fixable (MAKE[0]="make -C ${kernel_source_dir} KBUILD_EXTMOD=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules" + ditto for clean)
• ndiswrapper - affected, dead upstream 🤷
• nvidia - affected, maybe fixable? (MAKE[0]="'make' -jnproc IGNORE_PREEMPT_RT_PRESENCE=1 NV_EXCLUDE_BUILD_MODULES='__EXCLUDE_MODULES' KERNEL_UNAME=${kernelver} module s")
• nvidia-open - similar to nvidia above
• openrazer - affected, fixable (MAKE="KERNELDIR=/lib/modules/${kernelver}/build make driver")
• sysdig - not affected
• v4l2loopback - affected, fixable. (sources .config, adds BUILD_EXCLUSIVE_KERNEL="REQUIRES CONFIG_VIDEO_XXX" based on based on { echo "$kernelver"; echo 5.18; } | sort -V -C;) Similar to the linked Intel/uvc?
• vhba-module - not affected
• virtualbox-host - not affected

From the above - there are two maybes (nvidia & nvidia-open) and the rest are easily fixable. Will chip through as time permits.

Aside: some packages seem somewhat borked (acpi-call, bbswitch, etc) aka PACKAGE_VERSION="#MODULE_VERSION#". Not sure if an Arch issue or upstream - will check as well.

from dkms.

• define transitionary period

my gut feeling says that must be rather two than one major release of all major distributions, the second phase with more annoying deprecation warnings

I expect that there are many third-party out-of-tree modules that are not part of any Linux distribution and that need (minor) adjustments for this proposed change ...

from dkms.

my gut feeling says that must be rather two than one major release of all major distributions, the second phase with more annoying deprecation warnings

Not sure I follow... Are you saying that dkms transition should be defined by Linux distribution releases?
If so, I don't fully agree - each one has their own schedule which is outside of our control.

Although before we even remotely get there, let's try and address the known problematic cases. IRL got in the way, let me see if I can open a PR or two.

from dkms.

Some out of tree kernel modules also add conditions based on which kernel you are building against, for example: https://github.com/intel/ipu6-drivers/blob/master/dkms.conf

This is very handy as you can have the same source tree usable for multiple kernel versions.

This is going to change further now for IPU6 drivers as in kernel 6.10 some more modules have been merged, and some even with differences (so the out of tree kernel module still takes precedence). I don't think it's a good idea to consider the dkms.conf configuration file as a static configuration at this point.

from dkms.