QT doesn't work well when mixed versions of its core libraries are
installed. Usually an emerge -avDu world solves the problem, but some
users tend to avoid this.
For example, lets say you have parts of QT 4.4.2 on your system. QT
4.5.1 is available and a user decides to manually update qt-core, or
to install KDE which has a QT dependency on a QT library not
installed. In these cases, portage will update only a part of the
installed QT libraries, leaving the system in a mixed state.
QT based apps don't like that. Others will refuse to build, others
will fail to run.
We've managed to experimentally block partial QT upgrades by adding an
RDEPEND to all QT libraries [1] in qting-edge overlay. Portage
understands this and throws out B blocks if you try to change versions
only in parts of QT, but upgrades/downgrades fine if you do them all
at once (or use -Du world).
This "fix" also catches stale QT libraries that nothing depends on
anymore because the user has removed whatever required them (and never
ran --depclean).
Unfortunately we've got reports from paludis users stating that they
can't update QT from qting-edge anymore.
What I'd like to discuss is the following:
1) Is there a saner way to achieve our goal of doing whatever is
possible to avoid mixed QT versions?
2) Is our implementation considered correct and acceptable by the PMS guys?
3) Whats the general Gentoo Policy on mixed versions? Do we care, or
is our policy "please -Du world"?
We've also managed to achieve the same thing by adding PDEPENDs to
each QT library for any other QT libraries that depend on it:
i.e. if qt-xmlpatterns depends on qt-gui, we add the following to qt-gui:
PDEPEND="
|| ( !x11-libs/qt-xmlpatterns ~x11-libs/qt-xmlpatterns-${PV} )
"
the above (expanded for all libraries) has the same effect as the [1]
RDEPEND but looks a bit more hackish.
thanks
[1] lines 30-59
http://github.com/gentoo-qt/qting-edge/blob/master/eclass/qt4-build-edge.eclass
--
Alex Alexander || wired
Gentoo QT && KDE Herd Tester
http://www.linuxized.com
