[arch-dev-public] Conclusion: DKMS modules

[Gaetan Bisson]

Sébastien,

[2016-03-23 22:28:36 +0100] Sébastien Luttringer:
> Unexpectedly we got the most feedback from persons who are not dealing
> currently with the burden of managing kernels and their modules.

It's been more than two weeks since Allan's original message; everybody
who wanted to contribute to this discussion has contributed. There's
really no need to try and discredit the whole thread with a classical
"the silent majority sides with me" fallacy.

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

Seriously, man, how do you go from "no one objects to having dkms" to
"we must provide dkms"?

I mean, we're all trying to have a reasonable discussion here. On this
mailing list more than anywhere else. Please refrain from jumping to
your own conclusions all the time, it's really annoying, in particular
when you have to twist the logic of other people's arguments for that.

Allan already pointed this out, but I feel like I must insist:

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

Absolutely no. We are a binary distribution. Binary should be the
default. Nobody but you argued otherwise.

> 6) Binary modules should be built from the dkms package.

Wow! Where on earth do you get crazy stuff like that from? It's never
been part of this discussion. And what purpose would his additional
requirement serve exactly?

I really wish you'd argue in good faith instead of simply trying to
steer things your way.

Cheers.

-- 
Gaetan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20160323/b1f8601e/attachment.asc>