[arch-dev-public] Conclusion: DKMS modules
seblu at seblu.net
Wed Apr 13 00:04:03 UTC 2016
On jeu., 2016-03-24 at 08:29 +1000, Allan McRae wrote:
> On 24/03/16 07:28, Sébastien Luttringer wrote:
> > On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
> > 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.
Maxime says exactly: "I feel that what Sebastien proposed, ie having built
modules only for linux and linux-lts, and DKMS everywhere else would be a
good compromise IMHO."
Unfortunately, I never proposed linux-lts, it was you.
So, I asked you the reason on IRC:
[2016-03-21 20:32:47] <seblu> amcrae: why do you want to manage core kernels
differently than others? And moreover, who cares of -lts nowdays?
[2016-03-21 23:50:44] <amcrae> seblu: I don't want to manage core kernels
different - preferably all kernels are provided with binary modules
Reading this, and as you were behind the "core kernels" group, I was expecting
you conclude to binary module for the arch kernel, dkms for the rest.
Which is not coherent with the "we are a binary distro", but a common ground.
> > 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.
I did, and
Maxime: "I am somehow biased and in favor of DKMS everywhere"
Florian: "Please go that route" (the route also refer to DKMS everywhere).
Bartłomiej: "IMHO we should have DKMS for all external modules"
Lukas: "I like the idea of having DKMS in the repo"
> > 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.
Yes, binaries are preferred, that was not my point. The keyword was flavor.
For example, vbox was pulling the binary modules for the -arch kernel by
default, not the -lts one or others. As we don't have a way to select the
correct kernel version I find more elegant to pull a virtual name which is
But like point 6 and 7, I feel you'll claim that is not part of the discussion.
So, let's see that later.
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: This is a digitally signed message part
More information about the arch-dev-public