Arch Linux User Repository

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

@reed1: You get this when doing what? % VBoxManage list extpacks Extension Packs: 1 Pack no. 0: Oracle VM VirtualBox Extension Pack Version: 4.2.18 Revision: 88780 Edition: Description: USB 2.0 Host Controller, VirtualBox RDP, PXE ROM with E100 support. VRDE Module: VBoxVRDP Usable: true Why unusable:

I got verr_pdm_devhlpr3_version_mismatch :(

Sure this may end up in conflicts. But that is still broken design by Virtualbox. Installing the files to /var/lib is not the right way either. Quoting the Filesystem Hierarchy Standard [0] about /var: > /var contains variable data files. This includes spool directories and files, > administrative and logging data, and transient and temporary files." and about /var/lib: > This hierarchy holds state information pertaining to an application or the > system. State information is data that programs modify while they run, and > that pertains to one specific host. I think the right way would be to make Virtualbox install files to ~/.VirtualBox/ExtensionPacks, while still accepting packages installed globally by pacman to /usr/lib/virtualbox/ExtensionPacks. [0] http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

@eworm: Firefox is a good example. Packages providing extensions are installed globally (in /usr) and users one are installed in there home. Virtualbox install user extensions in /usr too, asking for super cow power and bypassing pacman. So, removing and readding this extensions by Vbox GUI will create conflict with next vbox package update. Nothing new. I started looking to define a new vbox extension path outside /usr (e.g: /var/lib/) to avoid all conflicts with pacman. w&s. $ find /var/abs -name *install|wc -l 1506

I second @eworm, system-wide files should be managed by pacman, this is how Arch works.

I do not agree. I think my example is relevant and valid. Take whatever package you like, usually there is no install script run by pacman after general package installation. Ok, back to firefox, it's a good example: A user can install extension. These extensions are installed on a per user basis, in user's home directory. I am fine with that. Virtualbox extensions however are installed globally in a world readable directory in /usr. Thus I think the files should be managed by pacman. About the different package... Well, I tried to contribute my changes to your packages. But it's all about choice: We do have a different point of view and I made it my way. Users now may choose what they prefer.

The install.sh provided as installer by firefox have the same purpose as pacman. Here we speak of a GUI provided by Virtualbox, after it's installation, to hot add (official or not) extensions into /usr or remove it without talking to pacman. Your example is not relevant. I love the idea to have all files in /usr managed by pacman, so your argument is challenging. But allowing users to re-add/add/remove extensions by the virtualbox GUI is convenient and not in our hands. I've the same logic in https://www.archlinux.org/packages/community/x86_64/virtualbox-ext-vnc/. Your prompt pushing of a different package is _not_ smart and don't help to improve things for both packages.

As Sébastien does not like the idea... I've uploaded my own package to AUR: https://aur.archlinux.org/packages/virtualbox-extension-pack/

I see it does. But that is not really a good reason to rely on that mechanism, no? Or did you download firefox.tar.gz and ran some crappy install.sh script? pacman should know about every single file installed to /usr, everything else is just broken.