[solved] virtualbox depends on virtualbox-host-dkms?

eschwartz · 2016-03-07 23:07:12

oconnor663 wrote:

For better or worse, I've learned to ignore optional dependencies. My guess is that most users have. I'm used to seeing long lists of things that really are optional, like what we have in the git package.

What an excellent comparison.

When I saw the long list of optional dependencies flying by for git, I immediately knew to install perl-mime-tools, perl-net-smtp-ssl, and perl-authen-sasl.
And wasn't I grateful to get the heads-up.

rlees85 · 2016-03-07 23:17:04

How will this work for users that have more than one kernel installed?

For example I have both linux and linux-lts, as linux tends to get bugs quite frequently and its good to just sit on lts for a bit until they get ironed out.

The old method was to just install virtualbox-host-modules and virtualbox-host-modules-lts and both just worked, no matter which kernel was running at the time.

I am guessing with DKMS I need both linux-headers and linux-lts-headers (fine both are installed anyway) but when the DKMS is triggered by a pacman update I am guessing I will only get the modules compiled for the currently running kernel?

This seems like a ballache from a user friendlyness point of view. But if the package maintainer found maintaining pre-compiled modules to be a total nightmare then so be it and I understand...

oconnor663 · 2016-03-07 23:30:34

I just filed https://bugs.archlinux.org/task/48498 referencing this thread. It sounded like there was an inappropriately-filed bug above, so apologies if I just repeated the same mistake.

eschwartz · 2016-03-08 00:24:57

rlees85 wrote:

I am guessing with DKMS I need both linux-headers and linux-lts-headers (fine both are installed anyway) but when the DKMS is triggered by a pacman update I am guessing I will only get the modules compiled for the currently running kernel?

The pacman hook is triggered by the installation or upgrade of any linux-headers package. I can't imagine why the dkms maintainer would want to further filter that by the output of `uname -r` but I promise you anyway that that isn't the case.

This seems like a ballache from a user friendlyness point of view. But if the package maintainer found maintaining pre-compiled modules to be a total nightmare then so be it and I understand...

The only issue(s) anyone should be having with this change whatsoever is "I don't want to install 45 MB worth of dkms miscellania" or "I didn't realize at first I would need to install the kernel headers for any kernel I want matching virtualbox modules for".

The first complaint is all about avoiding unnecessary development tools, the second complaint is user error.

eschwartz · 2016-03-08 00:26:15

oconnor663 wrote:

I just filed https://bugs.archlinux.org/task/48498 referencing this thread. It sounded like there was an inappropriately-filed bug above, so apologies if I just repeated the same mistake.

Actually, this is one of the first sensible things anyone has said in this thread.

Edit: @all, it is asking for a "kernel-headers" provides, to force people to have at least one set of headers installed.
That would prevent the "user error"-prompted complaint.

Last edited by eschwartz (2016-03-08 00:29:51)

oconnor663 · 2016-03-08 00:49:40

I also posted https://www.reddit.com/r/archlinux/comm … x_a_recent. I'm worried that this dependency issue is going to really screw a lot of people.

Eschwartz wrote:

"I don't want to install 45 MB worth of dkms miscellania"

This change means that `pacman -Syu` takes an extra 30 seconds on my machine, when it has to build kernel modules. Laptops and smaller machines will fare worse.

I'm also worried that we'll expose people to subtle configuration issues. For example, say you put some wacky GCC-related environment variables in .bashrc two years ago, to work with some random open source project. Now those variables break the virtualbox-host-dkms build, but you've long since forgotten that they exist.

Of course in general Arch users are expected to do some troubleshooting, and we can't handle every random config that might be out there. But the big difference here is, this is a *dependency* change for a widely-used, user-facing package. Like the linux-headers issue above, people are going to run into this in the middle of `pacman -Syu`, when they don't realize they're doing anything interesting. There won't be any indication of why this build is happening at all, much less why it's breaking. Etc. etc.

eschwartz · 2016-03-08 01:00:34

Taking a long time is another good point.

But I don't think your .bashrc matters, since dkms is being run in a (ch)root shell by pacman and it doesn't use your env. If only because sudo dropped your env anyway.
(Allowing your env to infect root processes would be a major security risk.)

oconnor663 · 2016-03-08 01:08:23

Ah good point. Does the example work if I say /etc/profile instead of .bashrc? :-D (That's the kind of thing sysadmins might do on a shared server in a company or university setting, though admittedly it's unlikely they'll be using Arch.) In general I worry that the list of ways to break this build is not short. There's a pretty big difference in my head at least, between users who take it upon themselves to compile kernel code, and users who like the stock packages and don't want to deal with any of that. Maybe that's old fashioned of me though.

Last edited by oconnor663 (2016-03-08 01:08:59)

fukawi2 · 2016-03-08 01:38:48

Have we had any response from the maintainer why the change was made in the first place? The thread on the ML seems very short. We have lots of reasons why it should be changed back, but I'm not sure we know exactly why it was changed in the first place. Personally I prefer it the way it was before (precompiled), but perhaps there is a good reason for the change that would change my opinion.

EDIT: another reason I dislike this change is it creates files in /usr that aren't tracked by pacman:

~ $ pacman -Qo /usr/lib/modules/*/kernel/misc/* 
error: No package owns /usr/lib/modules/4.1.19-1-lts/kernel/misc/vboxdrv.ko
error: No package owns /usr/lib/modules/4.1.19-1-lts/kernel/misc/vboxnetadp.ko
error: No package owns /usr/lib/modules/4.1.19-1-lts/kernel/misc/vboxnetflt.ko
error: No package owns /usr/lib/modules/4.1.19-1-lts/kernel/misc/vboxpci.ko
error: No package owns /usr/lib/modules/4.4.3-1-ARCH/kernel/misc/vboxdrv.ko
error: No package owns /usr/lib/modules/4.4.3-1-ARCH/kernel/misc/vboxnetadp.ko
error: No package owns /usr/lib/modules/4.4.3-1-ARCH/kernel/misc/vboxnetflt.ko
error: No package owns /usr/lib/modules/4.4.3-1-ARCH/kernel/misc/vboxpci.ko

Last edited by fukawi2 (2016-03-08 03:43:01)

Scimmia · 2016-03-08 03:23:36

oconnor663 wrote:

For better or worse, I've learned to ignore optional dependencies.

That is a serious problem. Expect your system to break regularly with administration like this.

fireandfuel · 2016-03-08 05:09:59

Can you simply revert the new dependency of virtualbox to virtualbox-host-dkms?
The precompiled virtualbox-host-modules package works fine, there is no need for the virtualbox-host-dkms package.

Allan · 2016-03-08 10:37:40

Scimmia wrote:

oconnor663 wrote:
For better or worse, I've learned to ignore optional dependencies.
That is a serious problem. Expect your system to break regularly with administration like this.

If your system breaks because not paying attention to optdepends, they were not that optional... That is poor packaging.

Scimmia · 2016-03-08 13:45:14

Allan wrote:

Scimmia wrote:
oconnor663 wrote:
For better or worse, I've learned to ignore optional dependencies.
That is a serious problem. Expect your system to break regularly with administration like this.
If your system breaks because not paying attention to optdepends, they were not that optional... That is poor packaging.

If you're system breaks because of not paying attention, you have nobody to blame but yourself. Period.

Malakin · 2016-03-08 18:04:33

This is not about not paying attention. This is about adding required "optional dependencies" without any notice when upgrading, in the wiki or in the front page.

midixinga · 2016-03-08 18:14:36

Scimmia wrote:

If you're system breaks because of not paying attention, you have nobody to blame but yourself. Period.

Hi Scimmia

you are right, we have to pay attention to pacman output. But in this case, all attention of the world had not not help me, because i didn't know DKMS really (and then I hit on the outdated wiki and tried to start DKMS with systemd<- NOT your fault) , and that it will build modules for me - if I install linux-headers. I hope, you can see this point.
Unfortunately I had this "user error" ((c) eschwartz :-) )

@Allan: If there is no way back to precompiled modules, do you have any idea, what would be a good packaging? What about this "provide" function of pacman, would it be workaround?
Thx

Last edited by midixinga (2016-03-08 18:18:35)

alphaniner · 2016-03-08 19:16:25

I don't use virtualbox or have any need of dkms, so I apoligize if this is naive:

If I understand correctly, provides don't conflict. Would it be possible to have the various header packages provide 'kernel-headers' and have virtualbox-host-dkms depend on 'kernel-headers'?

eschwartz · 2016-03-08 19:20:26

alphaniner wrote:

I don't use virtualbox or have any need of dkms, so I apoligize if this is naive:
If I understand correctly, provides don't conflict. Would it be possible to have the various header packages provide 'kernel-headers' and have virtualbox-host-dkms depend on 'kernel-headers'?

That is exactly what was proposed above, and filed on the bugtracker as https://bugs.archlinux.org/task/48498

Although I think it is sufficient for dkms itself to have the dependency.

oconnor663 · 2016-03-08 19:31:19

alphaniner wrote:

If I understand correctly, provides don't conflict. Would it be possible to have the various header packages provide 'kernel-headers' and have virtualbox-host-dkms depend on 'kernel-headers'?

I believe that's right. Sebastiaan Lokhorst clarified that for me on the mailing list.

I think what I'd like to see is for `virtualbox-host-dkms` to take a provided dependency on `kernel-headers-blah`, which must be satisfied by at least one headers package, and for `virtualbox` to take a provided dependency on `virtualbox-host-moduels-blah`, which must be satisfied by either `virtualbox-host-dkms` or the original `virtualbox-host-modules`. This double-virtual-dependency setup would help with a bunch of different problems:

1. People running other kernels wouldn't be required to install dependencies they don't use.
2. People running the regular kernel wouldn't be required to install dependencies they don't use, or to build modules from source.
3. People who've wound up in a confusing broken state would get automatically fixed, by being forced to install headers. (This is the real reason I think the complexity of a second virtual dependency is worth it, at least temporarily.)

Allan · 2016-03-08 21:37:26

Scimmia wrote:

Allan wrote:
Scimmia wrote:
That is a serious problem. Expect your system to break regularly with administration like this.
If your system breaks because not paying attention to optdepends, they were not that optional... That is poor packaging.
If you're system breaks because of not paying attention, you have nobody to blame but yourself. Period.

If dependencies are labelled optional, but are not optional, it is bad packaging.

Nooblazor · 2016-03-08 22:01:58

For the time being I just ran:

pacman -Syu --ignore virtualbox,virtualbox-host-dkms

in order to avoid dkms getting installed even if I answer that I want to keep the old modules.

Going to keep an eye on this topic and only take the steps necessary to setup dkms if I must.

oconnor663 · 2016-03-08 22:11:05

Nooblazor wrote:

For the time being I just ran:
pacman -Syu --ignore virtualbox,virtualbox-host-dkms
in order to avoid dkms getting installed even if I answer that I want to keep the old modules.

That might run you into a different set of problems pretty soon, if the `virtualbox-host-modules` package is not kept up to date. @Scimmia mentioned earlier in this thread:

Scimmia wrote:

Binary modules are a huge pain. The kernel breaks the module interface every couple of releases (and I'm taking micro-version, bug fix releases) with no warning and no way to tell until things fail.

alphaniner · 2016-03-08 22:27:21

Scimmia wrote:

Binary modules are a huge pain. The kernel breaks the module interface every couple of releases (and I'm taking micro-version, bug fix releases) with no warning and no way to tell until things fail.

OT: I suggest this to anyone who thinks Scimmia is exaggerating.

rlees85 · 2016-03-08 22:30:21

oconnor663 wrote:

Nooblazor wrote:
For the time being I just ran:
pacman -Syu --ignore virtualbox,virtualbox-host-dkms
in order to avoid dkms getting installed even if I answer that I want to keep the old modules.
That might run you into a different set of problems pretty soon, if the `virtualbox-host-modules` package is not kept up to date. @Scimmia mentioned earlier in this thread:
Scimmia wrote:
Binary modules are a huge pain. The kernel breaks the module interface every couple of releases (and I'm taking micro-version, bug fix releases) with no warning and no way to tell until things fail.

Same here. Might want to add your kernel & headers to the ignore list also and it is only a *very* temporary solution until it is set in stone that DKMS must be used going forward.

I am with Allan - the binary modules seemed a better and cleaner solution in my eyes (for the reasons already mentioned by many others above) as an end-user with multiple kernels. I won't throw my dummy out the pram over it though so please don't flame this post I am just adding my personal opinion.

Scimmia · 2016-03-09 00:07:35

rlees85 wrote:

I am with Allan - the binary modules seemed a better and cleaner solution in my eyes (for the reasons already mentioned by many others above) as an end-user with multiple kernels. I won't throw my dummy out the pram over it though so please don't flame this post I am just adding my personal opinion.

I don't think anyone's going to flame you over a simple opinion. Personally, I agree with you, I prefer the binary module packages. I also understand the problems they come with, though, so I can understand why the change was made.

Last edited by Scimmia (2016-03-09 00:08:06)

Scimmia · 2016-03-09 00:14:14

They way I see this, there are 3 separate issues at play here.

1. The dkms package doesn't enforce installing a kernel header package. This is being discussed here: https://bugs.archlinux.org/task/48498
2. The dkms package moved to hooks before it should have. This is being discussed on the mailing list in arch-dev-public, see previous links in this thread.
3. The virtualbox package is moving to DKMS only. This is also being discussed in the mailing list thread. Nobody has yet filed a coherent bug report about this.

Arch Linux

#51 2016-03-07 23:07:12

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#52 2016-03-07 23:17:04

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#53 2016-03-07 23:30:34

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#54 2016-03-08 00:24:57

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#55 2016-03-08 00:26:15

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#56 2016-03-08 00:49:40

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#57 2016-03-08 01:00:34

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#58 2016-03-08 01:08:23

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#59 2016-03-08 01:38:48

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#60 2016-03-08 03:23:36

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#61 2016-03-08 05:09:59

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#62 2016-03-08 10:37:40

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#63 2016-03-08 13:45:14

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#64 2016-03-08 18:04:33

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#65 2016-03-08 18:14:36

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#66 2016-03-08 19:16:25

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#67 2016-03-08 19:20:26

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#68 2016-03-08 19:31:19

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#69 2016-03-08 21:37:26

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#70 2016-03-08 22:01:58

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#71 2016-03-08 22:11:05

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#72 2016-03-08 22:27:21

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#73 2016-03-08 22:30:21

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#74 2016-03-09 00:07:35

Re: [solved] virtualbox depends on virtualbox-host-dkms?

#75 2016-03-09 00:14:14

Re: [solved] virtualbox depends on virtualbox-host-dkms?

Board footer