[arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

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.

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

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

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

Cheers,

[1] https://lists.archlinux.org/pipermail/arch-dev-public/2016-February/027770.
html
[2] https://bugs.archlinux.org/task/48498



-- 
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/20160309/bb0d8db5/attachment.asc>