Qt/FAQ

Why do I need qt3support?
First of all, qt3support is a useflag that enables the module in Qt4, as well as needed code in other Qt4 modules. It does in no way depend on Qt3. It contains classes that make porting Qt3 applications and libraries to Qt4 easier. They are Qt4 classes that emulate Qt3 behavior. This is really only interesting for the developer of that package, not for the user.

Any Qt4-based package that uses these classes from Qt4's qt3support will require the qt3support useflag to be enabled. This means the useflag needs to be enabled for all Qt4 modules that have this useflag. Enabling it for one but not other modules would break things, either at compile time or at runtime, so we force the usage: it must be either enabled or disabled for all Qt ebuilds. And as there is no package other than the Qt libraries themselves that use this useflag, the recommendation is to enable (or disable) it globally in make.conf.

As kdelibs-4 uses these qt3support classes internally, there is a genuine requirement for qt3support to be enabled. There is no way you can have KDE4 without qt3support in Qt4. But this does not at all mean you need to keep Qt3 itself around. We strongly recommend you to remove x11-libs/qt:3.

Users who do not use KDE, or anything that depends on, should be able to have most other Qt4 applications work without qt3support.

Why do I get blockers when trying to emerge Qt?
Gentoo uses split ebuilds of the various components of Qt to allow finer-grained control of dependencies from other packages and reduced compilation time for revision bumps or USE changes. However, despite there being separate ebuilds all those components must be of the same version, which means they must all be upgraded together.

If some of the updated version packages are keyworded but others are not, you get those blockers.

Another source of Qt blocks is incompatible USE flag combinations, the portage output should tell you which those are.

Blocks caused by mixing stable and testing versions
Mixing stable and testing versions is discouraged. Currently, when users want to install both Qt4 and Qt5, it is necessary to add a dev-qt/* entry to package.keywords, because Qt5 can only be installed in parallel with >=qtcore-4.8.6-r1. This dependency is enforced by qtchooser, a helper package that can set environment variables for the default Qt environment, see

qtwebkit vs chromium block caused by icu
A block might appear between and, because we do not enable the icu USE flag by default. If you want to install chromium as well as qtwebkit, then you have to set custom USE flags for the latter (or set them globally if you like). This can be done in two ways:

Disabling gstreamer means you will not get HTML5 audio and video capability in qtwebkit-based applications.

Solving the block
After you have checked your keywords and USE flags are set correctly, if you still get unresolvable blocks, then the easiest (not necessarily the best, but the one with the least headaches) way to get the blocks out of the way for a Qt upgrade is to uninstall all Qt components, and then emerge the new version:

1. List all installed qt packages:

2. Save tarballs of the old versions should we have to roll back:

3. Unmerge old version and emerge new version:

Should we need to roll back, then we can emerge the packaged versions:

What does the exceptions USE flag do?
The USE flag description is technical, because the issue is technical. It is enabled by default, because this is the recommended setting for Qt. See for a discussion. When a developer uses exceptions in his program, it will then produce a warning on certain errors, instead of a crash. This is a good thing, which we generally want. The downside is that the application will use some more memory and disk space. So in cases where those are limited (think for example of embedded environments) it could be useful to turn exceptions off. That is why we have decided to offer a USE flag to disable this feature, after some users requested this.