[arch-dev-public] Virtualbox binary modules maintainer

[Dave Reisner]

On Wed, Jul 16, 2014 at 09:05:50PM +0200, Sébastien Luttringer wrote:
> On 16/07/2014 19:39, Dave Reisner wrote:
> > On Wed, Jul 16, 2014 at 07:26:16PM +0200, Sébastien Luttringer wrote:
> > I guess this is/was you?
> It was Bartłomiej.
> 
> > I'm not interested, but this is pretty vague. How much time is involved?
> > How often? Are there open bugs? Have you worked with upstream at all? Do
> > they suck?
> 
> From upstream tarball, I create virtualbox-host-dkms and
> virtualbox-guest-dkms (split packages from virtualbox pkgbase). This is
> the "official" way of building vbox* kernel modules. All "real" modules
> bugs are handled in the virtualbox package.
> 
> To provide pre-compiled version of these modules for our linux and
> linux-lts packages, we have virtualbox-modules and
> virtualbox-modules-lts. Each one generate 2 packages, one for modules
> required in the hypervisor and one for modules required in the vm.
> 
> Note: We don't provides pre-compiled modules for linux-grsec.
> 
> AFIR, rebuild of these packages occur when:
> - New release of virtualbox (I handle them)
> - New release of the attached kernel package
> - Someone open a BR because a rebuild was not done when the kernel was
> updated.
> 
> There is currently one open bug report, which will be fixed when I will
> push the last release of vbox tonight.
> 
> You can have an idea of the time needed looking at the package history[1].
> 
> 
> > DKMS is pretty lousy without hook functionality in the package manager.
> > The whole point is that you can trigger this seamlessly on
> > install/upgrade.
> I'm not sure the package manager is an issue here, what we want is
> build vbox modules for the running kernel.

...and you want to build modules for the kernel that was just installed,
hence, you need package manager integration. See below for why you
should care about this.

> If you enable dkms service, the modules you need for kernel you are
> running will be built and loaded during the boot. It's transparent.

Building modules on boot is doing it too late. It's on the same plane as
what our initscripts used to do -- call 'depmod -A' on bootup. It's too
late, and you're asking for a race condition. What about dkms-based
modules which you're trying to build into the initramfs? You now need to
circumvent this whole process, build the modules manually, and then
rebuild your initramfs.

Calling this early enough that it tries to avoid some of the races will
just mean that you're unnecessarily blocking boot for X minutes while
you build modules. Unless I'm missing something, that's a lousy user
experience.

Please, if you really want this to be some defacto standard for how we
handle third-party modules, we *really* need someone dedicated to adding
hook support in pacman.

> The problem is more around our way of dealing with kernel updates
> (removing running kernel headers) than pacman packages ordering. We
> already don't support the case when user upgrade the kernel and don't
> reboot (kernel vs modules mismatch) immediately.
> 
> > There *will* be bug reports if you just drop these packages.
> Could you be more specific?

If you're touting DKMS as the new hotness, you will absolutely need to
have replaces/conflicts on the DKMS package for the packages you want to
obviate. Otherwise, these packages will remain installed and eventually
conflict with a kernel update. Around that time, you'll see bug reports.

> I have the feeling that using dkms packages will prevent bug reports
> coverings depmod or packages was not rebuilt for the current kernel.
> 
> This also simplify management for non official kernels.

This doesn't make sense. As I see it, nothing is simplified, because
nothing changes for this use case. User-built kernels can use DKMS now,
and they'll still be able to use after this change. The precompiled
module packages never had any relevance.

> Cheers,
> 
> [1]
> https://projects.archlinux.org/svntogit/community.git/log/trunk?h=packages/virtualbox-modules

Looks like 6 people (including yourself) have handled about ~4 builds
per month over the past year. Higher maintenance than most packages, but
certainly no higher than the cost of maintaining a single kernel package
(assuming you're Doing It Right™).

Are you, as the virtualbox maintainer, not willing to accept this shared
responsibility?

d