[arch-dev-public] Conclusion: DKMS modules

[Sébastien Luttringer]

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
decree.

==

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. 

7) https://bugs.archlinux.org/task/48498
==> 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).

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20160323/58e6b69c/attachment.asc>