[arch-dev-public] DKMS modules for virtualbox

[Allan McRae]

On 09/03/16 09:29, Sébastien Luttringer wrote:
> On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
>>
> 
> Before going technical, I want to make a quick summary of what happened so far.
> Earlier in February, I started a thread on this ml about improving our "out of
> tree modules" management with dkms. My planned final step[1] was to let vbox
> rely on this solution and so drop the binary modules. I pushed a vbox package
> in testing and feedback was requested. 8 days later, the openssl rebuild came
> up and moved vbox to community. This pushed vbox out of testing a bit too fast
> (no message, no enough test). So we are now.
> 
>> What are the advantages from a user perspective? 
> Have all its vbox modules the same way whatever kernel it uses (-arch, -lts,
> -grsec, -zen-, -custom).
> 
>> Why are we no longer shipping virtualbox modules pre-build?
> It removes the sync burden of kernel upgrades and its modules upgrades from the
> maintainers.
> Knowing that I have a 512Kbit/s connection at home, that not nothing to me.
> 

All users of virtualbox-host-modules now have to download 350x more to
update the modules for each kernel update.  In fact, it is worse than
that, because some kernel updates do not require module rebuilds but
will have a new headers package.

>> Is this happening for any other modules?
> In my knowledge, there is no global plan. Even I would like have all our binary
> modules have its -dkms counterpart to properly handle each kernel flavours.
> 
> Currently, we have both kind of modules in our repo. ndiswrapper is provided
> with no binary and bbswitch is only binary. So both way seems acceptable.
> 
>> Bad things I see:
>> 1) pre pacman-5.0 updates unsupported without any prior notification
> Interesting. This issue will also be present if we move other stuff like
> update-desktop-database to hooks, right? Do we have a way to detect pre-pacman
> 5 update to display a warning or handle it correctly?

There needs to be a public announcement made that we expected everyone
to have updated to pacman-5.0 by <insert date here>.  Then we start
using hooks.

>> 2) notification of need for linux headers is only given (optional dep)
>> in update that needs them for building.  There is no reason given why
>> they are optional dependencies.  There is no notification that the build
>> did not go ahead at the end of the transaction.
> I agree, this is not good, but this is not something new for users of dkms
> packages. dkms modules never pull a particular version of the kernel headers
> because there is no reason to deps on linux-headers more than linux-lts-header, 
> linux-zen-headers, linux-grsec-headers. What we want is to pull at least one
> kernel header.
> 
> A bug report[2] was opened, and I hope we will find a solution with kernel
> maintainers to request kernel headers to be present not depending on the
> flavor.
> 
> I will add a message in the dkms alpm hook to notify when kernel headers are
> missing and prevent module installation when only headers are present (causing
> issue with later kernel installation).

That will fix the use of "optdepends" for things that are not optional
(this is not the only package that does this...)

>> 3) Update is now a lot slower and this is repeated over a lot of users)
>> 4) additional download/install size (linux headers + module source).
>> 5) I don't want to have compiler or kernel headers installed.
>>
> I acknowledge that.
> 
> I like the idea of having several flavor of the Linux kernel inside Arch Linux
> and I would like we have a proper support of out-of-tree-modules for all of
> them. Moreover, I hope we will introduce versioned kernel to fix the kernel
> upgrade which remove the current running modules or break the boot.
> All of this will multiply the complexity of the sync between binary modules and
> the kernel release for packages maintainers.
> 
> As we currently not have the infrastructure to build binaries modules each time
> a new kernel version (flavoured / versioned) is pushed, 

Surely that is a five line script...

> dkms seems a good
> trade-off if we want to move forward this way.
> 
> So, even I think we should not, I'm not against having binary modules for vbox
> in cty, but I would use dkms as default and let the maintainer of the binary
> modules handle them.

We are not a source based distribution.  Binary packages should be the
default.

I have no objection to dkms versions being present (I believe they have
been for a while).  I only object to not having binary modules by
default for our primary kernels (i.e. the ones in [core])

A