[arch-dev-public] Virtualbox binary modules maintainer

[Sébastien Luttringer]

On 16/07/2014 22:13, Dave Reisner wrote:
> 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:
> 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. 

I am embarrassed I don't see why it's too late. I'm doing this for 3
years, maybe I'm a lucky idiot. We also have users who use vbox-dkms
package doing this without any bug report about a race condition.

> What about dkms-based modules which you're trying to build into the initramfs? 
There is few reason to embed vbox modules inside the initramfs, but
anyway, I guess it's up to the initramfs software you use to trigger the
build of dkms managed modules (for the requested kernel) it wants to ship.

We can have an mkinitcpio hook which build all the dkms modules for the
targeted kernel.

However, the pacman ordering issue is back, until next release of
pacman... which is, fortunately, expected in august.

> 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.
The build can continue far after your KDE desktop environment has
started. If you run virtualbox GUI before the build finish you will get
the message that modules are missing. I think our user are able to deal
with that.

> 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.
I'm only suggesting this for virtualbox modules, but, you are right, we
can simplify our way of managing all external modules by using dkms.

I know there are pros and cons to this solution, that's a team decision,
not mine. I see this as a better simple stupid solution with our
currrent tools.

>>> 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.
ok, you are talking of bug reports during the transition phase.

So, if we do that, we should handle the transition smartly. I think to
replaces/conflits and advertise in .install. We can even put a global
announce if you think it's necessary.

Don't believe that I'm in love with dkms. It's an helpful crap. I would
prefer have a brand new Lennart systemd glue[1] or anything more elegant
to manage out-of-tree modules. But it's currently the most spread solution.

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

Remember the title of my mail. I didn't start by "Burn the vbox
modules". I'm looking for someone who want to be maintainer of these
packages to handle official kernels rebuild and deal with bug reports.

Of course, I would prefer to drop them, because I feel them unnecessary.
They slow down the release process (of the kernel and virtualbox) and
cause issues.

Cheers,

[1] With depends (and wait) on modules instead of using
systemd-modules-load.

-- 
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: 815 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20140716/90833b98/attachment.asc>