FS#51321 - please restore the qtchooser package

Attached to Project: Arch Linux
Opened by Shawn Rutledge (ecloud) - Tuesday, 11 October 2016, 08:53 GMT
Last edited by Antonio Rojas (arojas) - Friday, 14 October 2016, 19:26 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

We discussed this in https://bugs.archlinux.org/task/51308 but I don't buy the assertion that if qtchooser exists, it makes it too easy to break your system. It does not need to be installed by default (most people don't need it), nor should it be a dependency of any Qt package; but having the package available (or at least having it in AUR) would not break the system of anyone who knows what they're doing with it.

Yes I can install things manually in /usr/local, but the reason for running a Linux distro (as opposed to building everything from scratch) is to have packages.
This task depends upon

Closed by  Antonio Rojas (arojas)
Friday, 14 October 2016, 19:26 GMT
Reason for closing:  Fixed
Additional comments about closing:  in AUR, won't support it officially
Comment by Antonio Rojas (arojas) - Tuesday, 11 October 2016, 09:39 GMT
If qtchooser exists then it needs to be a dependency of Qt because it provides commands that are expected by Qt applications. And they usually expect a specific version of Qt and will break if they point to the other one.
Take Plasma for instance: it runs qtpaths at startup and expects to find the Qt5 version. If someone points qtchooser to the qt4 version and tries to run plasma, it will fail. So we need to patch plasma to make sure that it calls the Qt5 version, and spend time rebasing our patch whenever the startkde script changes and updating it every time new calls to Qt binaries are added. Multiply that by the number of packages that rely on Qt binaries.
So, even if just for the maintenance burden it adds on package maintainers, supporting qtchooser officially is a bad idea.
Comment by Shawn Rutledge (ecloud) - Tuesday, 11 October 2016, 12:14 GMT
I see... so having the symlinks in the path by default is problematic; so you want Qt5's binaries in /usr/bin directly instead. Well it's kindof like icecream then - put the symlinks somewhere else, where someone who wants to use qtchooser can prepend that dir to his path?

(Details: icecream puts the symlinks for c++, gcc, g++ etc. in /usr/lib/icecream/libexec/icecc/bin, but that varies from package to package and from distro to distro, so my "universal" .bashrc has to search several places. I have an alias "iccon" which adds it to my path, and another alias "iccoff" to remove it. And had to implement it differently again for fish.)
Comment by Antonio Rojas (arojas) - Friday, 14 October 2016, 19:24 GMT
Sure, there you go https://aur.archlinux.org/packages/qtchooser/

Feel free to adopt it and modify it to your convenience.

Loading...