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
