[Development] New proposal for the tool naming

BRM bm_witness at yahoo.com
Mon Oct 22 16:33:15 CEST 2012

The more I read the various related threads, the more I think if qt-project is to do anything it should be to define to LSB/FHS how to configure Qt. I don't necessarily see consensus; but I do see a lot of questions that have gone unanswered. There seems to be a lot of objection to user tool name changes, for the sole benefit of only a portion of the community while having an adverse impact on the (perhaps) larger section of the community.

1. Qt should be installed to a self-contained directory, much like SDK and self-compile users. So Distributions should be discouraged from installing tools directly to /usr/bin, etc.
For example, install it all to /usr/share/qt5.0.0 just like the SDK.

2. Distributions should be encouraged to user their existing tooling to enable users to easily switch between different versions of Qt that the distribution supports; perhaps with support for users to register their own custom installs as well. This would be responsible for managing symlinks of all the user/developer visible tools that the distribution wants to put in the public paths (e.g. /usr/bin). This is very distribution specific - e.g. Gentoo would likely use their eselect tool much like they do for python, gcc, default editors and an host of other tools; while other distros would use tooling of their own style that meets their distribution needs in ways that are consistent with their distribution.

This would alleviate any need for qt-project to resolve the issue, while showing distributions how it ought to be done.
So instead of renaming tools, let's set a standard for how to install Qt in LSB/FHS; one that can apply to more than Qt if LSB/FHS desires it.
Any Unix system could adopt the same kind of standard set by LSB/FHS as a guideline as well.

Personally, I think renaming things is probably the wrong way to go about solving this issue as numerous tools and environments have qmake and other tools/libraries coded that will need updated - some obviously, some not so obviously.

For whatever it may be worth,



More information about the Development mailing list