Arch Linux User Repository

There is no version dependency on this package on purpose! You could read comments back from 2011 to understand why.

Well I don't particularly prefer building my packages myself. But I do if the package I want frustrates me - always pulling in an unnecessary and unwanted dependency counts as frustrating in my mind. So thank you for your tip with "makepkg -d" but I already figured out my way of creating the package the way I want it. But what's up with that "That's damn faster"? My complaint is not about speed (but if it was I would ask as to why you are actually unpacking the extpack, then rm the created files and repacking it instead of for instance piping it throught tar and use the -X/--exclude switch or anything but actually decompressing, altering files and compressing again), my complaint is about keeping things simple and without unneeded stuff. So far I still couldn't come up with a sigle scenario in which a user has successfully installed virtualbox yet would run into trouble with this package if it hadn't that -dkms makedep. And this is the only package I've come across that finds that "-dkms trick" necessary. Really, I would like to understand in which case this trick is useful and why. But reducing build time is not a valid reasoning in a package like this in my mind. Your next statement about eworm's package raises the question: What should be in charge of keeping track of packages and/or it's files? A distribution's package manager or should third party tools such as VBoxManage be trusted to manipulate files while wielding root privileges? While that could actually be an interesting question it is too abstract for this comment section. And I understand that you're just trying to comply with virtualbox by letting vbox handle it's ext-pack-files, even though they're not tracked by the package manager. I can even accept that approach if that's the only official option given by vbox and if one is worried about things breaking in vbox if not installed the "official way". But please give the idea of forcing dkms on the virtualbox package a second thought. Because as great as dkms can be for servers as questionable it's usefulness is for desktops and medium workstations and more importantly: There is still no way for pacman to keep track of files created through dkms. And there is no official vbox rule I am aware of that would force one to use virtualbox specifically with dkms. So no need to hurry into a technology that isn't yet fully worked through just because it's cool. If however you as the maintainer deem dkms really necessary I feel like the virtualbox package would be the proper place to dep on dkms and not this pkg which only relies on vbox. And again, in that case I would like to know who that would be necessary for to force dkms on all users. Not to troll, just to learn. Lastly just for the record (not a perfect example, but one I quickly came up with): For example the nvidia package deps on a specific linux-package version range just like the virtualbox package. Yet other packages like nvidia-utils or opencl-nvidia don't seem to be in need for a -dkms trick. Also the nvidia package copies and tracks the module directly, bypassing the installation routine. Just one of many packages that deal with these issues that way. best regards

I will probably remove this dep soon, as virtualbox will dep on virtualbox-host-dkms. Nonetheless, this package takes care of this, to reduce the build time in a chroot; If you prefer build your package with makepkg, I suggest you to use "makepkg -d" instead of creating your own package. That's damn faster. eworm's package is a fork (or duplicate) which bypass the virtualbox official way for installing external modules., by dropping somes files directly inside the virtualobx directory.

Honestly I fail to see the need of virtualbox-host-dkms makedeps too. Correct me if I'm wrong/missing something, but you said you included it only so virtualbox-host-modules won't be triggered to pull the arch stock kernel. But why would this package need to take care of this? Basically this package here tries to "fix" dependencies higher up in the dependency tree. And that part doesn't make a lot of sense to me. Plus this is only the case if someone is using a non-stock kernel to which there is no adapted virtualbox-host-modules package but in that case they wouldn't be able to install virtualbox in the first place. Even if there are such cases that require that "virtualbox-host-dkms trick" I (again, just my personal opinion, I may be wrong) would deem that a special and rare case that should better be treated in a special package, for example virtualbox-ext-oracle-dkms. I was using this package for a long time but this in my (and I assume by far most scenarios) pointless dependency that's always pulled by this package led me to create my own pkgbuild maybe like two years ago when this -dkms shennanigans started. Just set up a new computer here and accidentally installed this package and was reminded of this issue here. I see that this package here and eworm's https://aur.archlinux.org/pkgbase/virtualbox-extension-pack/ are coexisting for a little over a year now. Maybe this package here should be renamed to something like virtualbox-ext-oracle-dkms?

build in a chroot is not an atypical way of building a package. All released packages should be build inside a chroot. Learn to use devtools to do accordingly. Btw it's a makedepends, not a depends of the package. You can still use makepkg -d, if you want to avoid this deps during build.

If it's there for a particular atypical setup (building in chroot), should it be there in the AUR for general consumption? That seems to be adding unnecessary packages to a lot of people's machines when very few of them actually need them.

$ wget -qO- 'http://download.virtualbox.org/virtualbox/4.3.10/Oracle_VM_VirtualBox_Extension_Pack-4.3.10.vbox-extpack'|md5sum 25b70fa71d9320e2836b9be138457ee0 - Good from my home. Bad from my office. There is probably a replication issue between Oracle mirrors. I already see that in the past. The md5sum is correct. @djhaines: Right, it doesn't require it to build. But the virtualbox deps pull virtualbox-host-modules, which pull linux kernel. Putting this makedeps deps avoid a kernel to be fetched when I build the binary package in a chroot.