From Gentoo Wiki
< Qt
Jump to:navigation Jump to:search

This is a list of frequently asked questions about the Qt framework.

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.

Common causes:

  • If some of the updated version packages are keyworded but others are not, those blockers appear.
  • Another source of Qt blocks is incompatible USE flag combinations; the portage output say which those are.

Solving the block

  1. Check /etc/portage for stale dev-qt/* entries (e.g. tightly versioned =dev-qt/foo-1.2.3 entries). Especially on stable systems. Either no Qt should be in package.accept_keywords or all of Qt needs to be in there. Optionally try checkworldfile.
  2. Check /var/lib/portage/world for any packages not personally needed. Libraries, dependencies, etc should not be in the world file.
  3. Run emerge -p -uvDU @world --backtrack=9999. If this isn't sufficient, continue on.
  4. Run emerge -pev @world --backtrack=0
    1. For any lines that say "there are no ebuilds to satisfy ...", there are a few options:
      1. emerge --deselect ... for any packages which are no longer desired
      2. Fix the issue preventing them being installed (e.g. add them to package.accept_keywords)
    2. Run until there are no fixable issues
  5. Try emerge -p -uvDU @world --backtrack=9999 again.
  6. Failing that, try emerge -p -uvDU @world --ignore-built-slot-operator-deps=y. This should reveal some more output and allow further diagnosis of the problem. It's best not to use this option to do the upgrade (without pretend) unless truly needed. If it is used for the full upgrade, one must run emerge -a -uvDU @world afterwards.

Sledgehammer approach

This doesn't fix the root cause at all. Needing to do this means the issue is likely to come up again in future because whatever stopped Portage from figuring out an upgrade path is still lurking. So, users who "need" to do this every time Qt is due for an upgrade actually need to dig deeper.
This obviously will break everything using the Qt libraries until they have finished emerging.

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:

List all installed Qt packages:

root #export INSTALLED_QT_PACKAGES=$(qlist -IC "dev-qt/*")
The qlist command is provided by app-portage/portage-utils

Alternatively, eix can be used:

root #export INSTALLED_QT_PACKAGES=$(eix --only-names -IC dev-qt)
The eix command is provided by app-portage/eix

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

root #quickpkg ${INSTALLED_QT_PACKAGES}

Unmerge old version and emerge new version:

root #emerge -Ca ${INSTALLED_QT_PACKAGES} && emerge -av1 ${INSTALLED_QT_PACKAGES}

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

root #emerge -av1 --usepkgonly ${INSTALLED_QT_PACKAGES}