[arch-dev-public] Conclusion: DKMS modules
allan at archlinux.org
Wed Mar 23 22:29:57 UTC 2016
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
> 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.
> 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
> 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.
More information about the arch-dev-public