Re: [arch-general] Missing Dependency virtualbox-host-dkms
I didn't force the deps to linux-headers because you could use the kernel (linux, linux-lts, linux-zen, linux-grsec, etc) you prefer (or all together). I will add a message with the next release of virtualbox.
Would it be possible to depend on a "Provides" that all the different kernel header packages share? Similar to how nvidia-libgl, catalyst-libgl, and mesa-libgl all provide the "libgl" dependency. That would solve the presumably-very-common case where users initially installed virtualbox without any host headers at all, and are now landing in a broken state by default. (Or would that mean that the different header packages conflict where they didn't before?) - Jack
2016-03-08 0:10 GMT+01:00 Jack O'Connor
Would it be possible to depend on a "Provides" that all the different kernel header packages share? Similar to how nvidia-libgl, catalyst-libgl, and mesa-libgl all provide the "libgl" dependency. That would solve the presumably-very-common case where users initially installed virtualbox without any host headers at all, and are now landing in a broken state by default. (Or would that mean that the different header packages conflict where they didn't before?)
Yes, I think that would be the best solution. Each '*-headers' package could provide 'kernel-headers' (or something like that). Provides does not imply conflict, so that wouldn't be a problem. Note that a user could still install a certain 'x-headers' which does not match their 'y' kernel, since the headers do not depend on the kernel or vice versa. (in the libgl case this is not a problem, since the libgl packages depend on the matching driver) But I think most users who use the regular kernel and are not familiar with other kernels would install the plain 'linux-headers' package when prompted, and not the 'linux-lts-headers' package or something else.
On Mon, Mar 7, 2016 at 6:52 PM, Sebastiaan Lokhorst
Yes, I think that would be the best solution. Each '*-headers' package could provide 'kernel-headers' (or something like that). Provides does not imply conflict, so that wouldn't be a problem.
Note that a user could still install a certain 'x-headers' which does not match their 'y' kernel, since the headers do not depend on the kernel or vice versa. (in the libgl case this is not a problem, since the libgl packages depend on the matching driver)
But I think most users who use the regular kernel and are not familiar with other kernels would install the plain 'linux-headers' package when prompted, and not the 'linux-lts-headers' package or something else.
Now that you mention it, would it be possible to have virtualbox depend on a "virtualbox-host" fake package that both virtualbox-host-modules and virtualbox-host-dkms Provide? That way end users wouldn't need to install any headers or make dependencies, and their updates would be faster, while folks on other kernels would still be able to satisfy the dependency their own way. Or is there another reason virtualbox-host-modules was dropped as a dependency? Unfortunately, "virtualbox-host" wouldn't automatically fix anyone who's gotten into the broken state, since they'll now have virtualbox-host-dkms installed, but it won't be building any vbox* modules for them. Maybe it would be a good idea to create *both* virtual packages? If that's more work than it's worth, an Arch News post might do the trick too. But people using virtualbox-host-dkms really do require at least one kernel package, and it could be helpful to have pacman enforce that.
participants (2)
-
Jack O'Connor
-
Sebastiaan Lokhorst