[arch-dev-public] Conclusion: DKMS modules
seblu at seblu.net
Wed Mar 23 21:28:36 UTC 2016
On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
> Having given everyone time to reply (not that many did...), the
> consensus of those that replied is:
> - Binary modules are to be provided at minimum of all kernels in [core],
> with preference to providing them for all supported kernels (noting that
> out-of-tree modules may not work with some patched kernels).
> - There is no objection to providing DKMS modules in the repos, but this
> is secondary to binary modules. No opinions were stated on whether we
> ensure all modules have DKMS variants in the repos.
> I decree by the power invested in me through talking the loudest, that
> this is now our policy.
Unexpectedly we got the most feedback from persons who are not dealing
currently with the burden of managing kernels and their modules. Like you I was
expecting more opinions.
Even I support your will of moving forward regarding all this discussion, I
don't share your conclusions nor the fact that one of us could speak lourder to
impose his will to others.
I have few more subjects to discuss altogether where
I hope we could take team directions by constructive discussions and not
I give a second read to all emails exchanged since my original one about o-o-t-
m at 19th February and I come to this:
1) No one support that we should manage kernels differently because they are
under different repository.
==> We must manage them all the same way.
2) No one object to a module exclusion from a specific kernel when it make no
sense Examples was provided with GRSEC.
==> We could exclude modules support for a kernel for technical reasons.
3) There is a consensus on having binary modules in our repositories.
==> We must provides binary modules for all kernels. Except those covered by 2.
4) No one object to having dkms available for all modules; It's even supported
by several fellows and this is offering support for AUR and custom kernels at
almost no maintenance cost.
==> We must provides dkms build for all modules. Except those covered by 2.
5) There is no much discussion about which should be the default (a binary
flavor or dkms). I would propose a solution which let the user choose which
module he want needs by pulling a defined dep like module-$modulename.
==> Applications should pull a generic deps to let users decide which module he
wants (flavored or dkms).
6) Binary modules should be built from the dkms package. This was not discussed
earlier, but I see a benefits to have a common way of building modules and
testing the dkms package in one row.
==> kernels packages should provides kernel=$version and kernel-
headers=$version in order to let dkms modules maintainers require at least a
kernel and its header to be installed.
This is the policy I propose we adopt.
Note that this policy is not defining who is responsible of what. We could keep
our current way of doing. I mean:
- When a kernel is upgraded, it's kernel maintainer responsibility to upgrade
all binary modules
- When a module is upgraded, it's the modules maintainer responsibility to
build the module for all kernels in stable and in testing (This is boring).
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: This is a digitally signed message part
More information about the arch-dev-public