Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#50116 - [virtualbox] move qt5-x11extras to dependency

Attached to Project: Community Packages
Opened by Allan McRae (Allan) - Thursday, 21 July 2016, 04:22 GMT
Last edited by Sébastien Luttringer (seblu) - Thursday, 28 July 2016, 20:40 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

All packages should have dependencies to run their primary binary. If you want to support a smaller install, you should split the other components out.
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Thursday, 28 July 2016, 20:40 GMT
Reason for closing:  Fixed
Additional comments about closing:  virtualbox 5.1.2-1
Comment by Mateo Buenacasa (Hawk412) - Thursday, 21 July 2016, 05:37 GMT
I can confirm this. I had virtualbox installed and running properly before this last major upgrade. Oracle's site mentions a migration towards qt and that could be the cause. I had only limited qt dependencies installed on my system and solved this problem by simply installing libQt5X11Extras package. This should have been pulled as a dependency on upgrade.

My error code:
supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: libQt5X11Extras.so.5: cannot open shared object file: No such file or directory
Comment by Doug Newgard (Scimmia) - Friday, 22 July 2016, 12:41 GMT
There's nothing to "confirm", Hawk412. The Qt dep has been optional for many years now, the only difference is that it changed from Qt4 to Qt5. Pacman told you about this change when you updated, if you bothered to pay attention to it. This isn't about a bug, more about packaging policy.
Comment by Aoibhinn di Torí (aoibhinnditori) - Saturday, 23 July 2016, 19:03 GMT
Well it is an issue when it doesn't work and you have to install the dependencies manually.
Comment by Doug Newgard (Scimmia) - Saturday, 23 July 2016, 22:57 GMT
No, that's by design. That's how optional deps work and always have.
Comment by André Miranda (andreldm) - Tuesday, 26 July 2016, 03:09 GMT
I'm sorry, but an optional dependency missing shouldn't prevent a user from using the package, because IMHO the majority of users do use virtualbox's GUI.
Comment by Sébastien Luttringer (seblu) - Tuesday, 26 July 2016, 23:53 GMT
Allan, I agree on what the subject is proposing (adding the qt5 deps) but I don't understand how you come to this with the concept of "primary" and "run".

1) net-tools and vde2 optdeps would also be added if I want to comply with "run". Why not suggest them?
2) the primary binary is confusing. Despite its name, virtualbox is a wrapper scrip to the Qt binary.

My understanding is that the root of this issue is the broken shared library, not which binary is important or if it has to works out of the box.
Saying we don't want to have broken shared library with all programs in a package is enough?

Currently we already have the SDL graphical backend as dep, adding the Qt one should be fine.
Comment by Allan McRae (Allan) - Wednesday, 27 July 2016, 01:14 GMT
If a package is named virtualbox, I expect running "virtualbox" to work (in general... of course there are weird naming issues everywhere). In this case, the wrapper script calls the Qt frontend, so we need the Qt dependency.

not-tools and vde2 are not required for virtualbox to run, only if you want network access (as far as I understand). That seems something that could be optional.

Loading...