[arch-dev-public] Conclusion: DKMS modules

[Allan McRae]

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