On Wed, Apr 13, 2016 at 08:07:34PM +0200, Bartłomiej Piotrowski wrote:
On 2016-04-13 15:44, Ike Devolder wrote:
On Wed, Apr 13, 2016 at 02:05:36PM +0200, Jan Alexander Steffens wrote:
On Wed, Apr 13, 2016 at 12:14 PM, Ike Devolder <ike.devolder@gmail.com> wrote:
To get this discussion back on the right track I'm going to build the binary modules for virtualbox. Sébastien and myself already discussed what will be done so relatively soon those binary modules will be back.
My plan is now to provide the virtualbox modules for -arch -lts and -zen. I think -grsec will be the exception since there are probably protections in there that will block some modules to even build.
And when everyone is happy again we probaly should proceed to provide dkms for all out-of-tree modules alongside the binary modules. That would benefit everyone and offer the greatest amount of choice. People using custom kernels can use dkms and have everything working that way and people using one of the kernels available in the repo's can choose if they want dkms or binary. Everyone wins.
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
That makes it easier for me. So we stick to binary modules for [core] kernels and the rest does dkms as a middle way.
Let's wait for Andreas opinion on this, but I think that binary modules for -lts are unnecessary. I always used this kernel for servers (where I don't really care about Virtualbox or Nvidia…) and sometimes a fallback if -ARCH is broken.
Bartłomiej
So after 2 or 3 mails we divert further from what I presumed was a sort of consensus. Could we just take this to a vote or something because this sort of impasse will only hurt the users. 1. vote for binary modules - -ARCH - [core] - other? 2. vote for dkms - all out-of-tree modules provide dkms - dkms if the maintainer of the module is willing to do it - no dkms (no longer an option I think) proposal flow for kernel + binary module updates - use separate repo [kernel-update{-testing,-staging}] - announcement to the module maintainers there is an update for a kernel - module maintainers build and push the packages in the respective repo - kernel maintainer can move kernel + modules in the main repo -- Ike