[Feat. req.] Support patches and scripts in `/etc/dkms/`

[cyqsimon]

Currently it's mandated that patches and scripts live in the root directory of the source, i.e. /usr/src/mod-ver/. No other locations are supported. However this is somewhat of a problem if /usr/src/mod-ver/ is managed by a package manager. Package managers usually make no guarantees that files placed here won't be deleted or overwritten, so manually changing stuff here is generally frowned upon.

Considering that there's already support for dkms.conf override in /etc/dkms/, I think it'd be a good idea to extend this a bit so that custom patches and scripts can be placed here too.

[scaronni]

What's the issue though with the current approach? The fact that the main folder of the modules is managed by a package manager does not mean you could have patches. Example:

• Package 1 owns /usr/src/foo-1.0
• Package 2 (or no package at all) owns /usr/src/foo-1.0/customstuff.patch, which is never touched by the package manager.

What is the use case for this? To carry around patches across multiple releases/versions of the modules?

[cyqsimon]

What is the use case for this? To carry around patches across multiple releases/versions of the modules?

Spot on. Here's the example that actually affects me. It happens somewhat frequently that RHEL kernel backports break existing modules; but in this case the package upstream is not very responsive to PRs. When they do push an update, often it still does not address my problem, but the files do get installed into a new directory. So within the current system I have to manually move /usr/src/gasket-oldver/my.patch to /usr/src/gasket-newver/my.patch.

Granted this is very much an upstream problem. But it would be nice if dkms has the flexibility to allow me to work around it.

[scaronni]

We already have the opportunity to specify DKMS snippets in the /etc/dkms like the following:

$ cat /etc/dkms/gasket.conf
PATCH[0]="my.patch"

So it seems to be a matter of only allowing a different location for it.

Seems doable. Will have a look. No guarantee on timeline.