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