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
signature.asc
Description: This is a digitally signed message part
