On 24/03/16 07:28, Sébastien Luttringer wrote:
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.
It was a joke. Although those of us that have been around here 10 years have loud voices...
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.
I did. Maxime said building modules for only linux and linux-lts is a good compromise. The Florian said "please go that route". Lukas was strongly in favour "of have binary modules for kernels from [core]". Gatean was in favour of having all kernels support binary modules. Hence my conclusion: "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)."
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.
Hence the "noting that out-of-tree modules may not work with some patched kernels" in my conclusion.
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.
See 1).
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.
As I said, no-one objected to DKMS modules. But no opinions were stated whether they must be provided.
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).
REALLY? You need to read that thread again. Default binary was strongly supported.
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.
Not part of the discussion. The maintainers of the packages can have a separate discussion about this.
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.
Off-topic for this discussion.
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
It already is, unless they put the package in [staging] and create a rebuild list. Same as every other package.
- 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).
It already is. If you don't like doing it, don't maintain the package. A