On Mon, Mar 7, 2016 at 6:52 PM, Sebastiaan Lokhorst <sebastiaanlokhorst@gmail.com> wrote:
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.