app-emulation/virtualbox-bin-2.1.0[1] is linked aganist libcap.so.1, but no 1.x ebuild is present in tree, please consider (if possible) to reinstate this ebuild. [1] see bug #251335 Reproducible: Always
Reassigning to base-system herd.
sys-libs/libcap-2.11 works fine with virtualbox. All that's required is a libcap.so.1 symlink.
Such a symlink is NOT GOING TO HAPPEN. That's *NOT* a solution, as the two libcap version have different ABIs. Fooling with the linker this way is going to break things in subtle ways.
Just a thought... Would it be possible / permissible to include libcap-1.x in the installation until it's fixed upstream? I placed a copy of libcap-1.10 from debian (it's a proxy filtering thing at work) in /opt/VirtualBox and it appears to be happy for me... I don't know if it would be better to drop a binary in the installation or compile it from source upon installation.
This may not be necessary. Virtualbox only uses 2 entry points to libcap (cap_set_proc() and cap_from_text()), and those are ABI-compatible between libcap1 and libcap2. I think it makes more sense to address this with an LD_PRELOAD in the virtualbox-bin package rather than re-introduce libcap1 (which apparently uses insecure kernel interfaces, thus the move to libcap2).
> This may not be necessary. Virtualbox only uses 2 entry points to libcap VirtualBox-bin 2.0.1 can't work with network with libcap2: Failed to open/create the internal network 'HostInterfaceNetworking-br0' (VERR_SUPDRV_COMPONENT_NOT_FOUND). Unknown error creating VM (VERR_SUPDRV_COMPONENT_NOT_FOUND). NS_ERROR_FAILURE (0x80004005) Console IConsole {e3c6d4a1-a935-47ca-b16d-f9e9c496e53e}
*** Bug 255792 has been marked as a duplicate of this bug. ***
if that's true, then you can cheat by doing this in the ebuild: dosym /lib/libcap.so.2 /opt/VirtualBox/libcap.so.1 all of the virtualbox binaries have RPATH's with $ORIGIN in them, so you can put the symlink in /opt/VirtualBox/ without affecting any other package
