oh, sorry, my fault; I had a look in my Backups; I lost group membership one month ago because of removing and reinstalling virtualbox
I did not recognize it, because my USB-Devices were still listed in the USB Settings
sorry for the suspicion
Search Criteria
Package Details: virtualbox-ext-oracle 7.2.2-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/virtualbox-ext-oracle.git (read-only, click to copy) |
---|---|
Package Base: | virtualbox-ext-oracle |
Description: | Oracle VM VirtualBox Extension Pack |
Upstream URL: | https://www.virtualbox.org/ |
Keywords: | virtualbox |
Licenses: | custom:PUEL |
Submitter: | seblu |
Maintainer: | seblu (eworm) |
Last Packager: | eworm |
Votes: | 1372 |
Popularity: | 4.02 |
First Submitted: | 2010-12-24 16:48 (UTC) |
Last Updated: | 2025-09-11 11:41 (UTC) |
Dependencies (2)
- virtualbox (virtualbox-svnAUR, virtualbox-binAUR)
- rdesktop (optional) – client to connect vm via RDP
Required by (1)
- virtualbox-bin (optional)
Sources (1)
Latest Comments
« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 43 Next › Last »
dixi_minga commented on 2014-08-29 05:00 (UTC)
seblu commented on 2014-08-29 02:17 (UTC)
How could you loose a group membership because of this package?
Fortunately we hunt duplicates on our spare time, my main mistake is to not have killed it quickly.
dixi_minga commented on 2014-08-29 01:34 (UTC)
Now it works, I lost my vboxusers group membership with the new package.
I know it's "only" AUR; but I'm not very happy, that the "Duplicate" was simply deleted.
seblu commented on 2014-08-29 00:37 (UTC)
@dixi_minga: It was removed as duplicate. Could you be a little more specific, why this one is not working for you?
dixi_minga commented on 2014-08-28 19:59 (UTC)
I cant find anymore the package virtualbox-extension-pack; this was the only one for me, which works ?
msx commented on 2014-08-19 09:46 (UTC)
Thanks for automating the install of the extension :)
hybrid commented on 2014-07-26 05:04 (UTC)
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
Pinned Comments
seblu commented on 2019-04-25 17:41 (UTC)
There is no version dependency on this package on purpose! You could read comments back from 2011 to understand why.