[arch-dev-public] Conclusion: DKMS modules

[Sébastien Luttringer]

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
provided.

But like point 6 and 7, I feel you'll claim that is not part of the discussion.
So, let's see that later.


Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20160413/846e2d2d/attachment.asc>