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