Bugzilla Automation <bugzi...@freebsd.org> has asked k...@freebsd.org for maintainer-feedback: Bug 242905: misc/qtchooser symlinks break users tools and qt5 deps https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242905
--- Description --- qtchooser seems to be less than ideal model... It installs a bunch of symlinks that confuse users other apps/tools into thinking that the particular symlinked binary/module exists or may do something useful, when in fact it does not. That causes variety of problems with those apps... commonly configure builders detecting optional things, etc. Repeat: Install qtchooser... ls /usr/local/lib/qt?/bin Diff that list to all the qtchooser symlinks in... ls -l /usr/local/bin | grep qtchooser Pick and exec any unneeded or not present app from there and see the confusion ensue... qmake: could not exec '/usr/local/lib/qt5/bin/qmake': No such file or directory moc: could not exec '/usr/local/lib/qt5/bin/moc': No such file or directory etc... Fix options: 1) qtchooser should not install any symlinks at all. Instead, whatever ports that want to use qtchooser should install themselves into their respective /usr/local/lib/qt hiers, then install their own respective symlinks to qtchooser in /usr/local/bin, and then depend on qtchooser (now just offering its bin and config). 2) qtchooser could be deprecated from the dependency list of all current ports since qt4 is gone... only qt5 exists. 3) Force users to manually install and maintain a bunch of unneeded ports, dependencies, qt modules... just to satisfy qtchooser's symlinks. This can cause more problems when those ports get out of date, conflict, etc. This option seems not an elegant minimal prospect. 4) The qt5 meta port should probably be made available as a package anyway. This might make pulling in (3) above easier. ?) ?
