From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-dev+bounces-36016-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1M5zhu-0001Wg-FC
	for garchives@archives.gentoo.org; Mon, 18 May 2009 10:04:30 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 1450CE0280;
	Mon, 18 May 2009 10:04:29 +0000 (UTC)
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186])
	by pigeon.gentoo.org (Postfix) with ESMTP id BE130E0280
	for <gentoo-dev@lists.gentoo.org>; Mon, 18 May 2009 10:04:28 +0000 (UTC)
Received: by mu-out-0910.google.com with SMTP id i10so1433173mue.6
        for <gentoo-dev@lists.gentoo.org>; Mon, 18 May 2009 03:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:date:message-id:subject
         :from:to:content-type:content-transfer-encoding;
        bh=Psu5bX+92n/aWY+Rbc95ARMkJPw8C4qVEaJ+RPz7KMc=;
        b=UI6dSu3JitQ+991U8Vni2+VS59nx8w1NIHxxqmJMNpvZODfptPd7Lp0itol+s42JJh
         WiGfIGG0bZjh3jVQghPBBe3TT1eaphb7Tt2/c/yzdyTZcN+ZDpy0MQyLSDUzehccmDSz
         S5WGXnQPye2MN241gP9X+ssAYEvlR8RiK3Lho=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=PfntHaE3pxxPiOCUoV1009MSeFMqnc1Zp4nvXBxhRMdmLTYD2GudyzZKKPfiNAa2sO
         1XhiPVU+x8TeJNfUeUuBaVM5JK03MxdZNyrx+OSLLXrVg0EE63sal5f2tXzZcKvGYK+B
         m8Tb/WeO0A79Dw6Q6EQ84YBKr5eOCP3Ki+gsU=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.102.215.1 with SMTP id n1mr3316063mug.109.1242641067870; Mon, 
	18 May 2009 03:04:27 -0700 (PDT)
Date: Mon, 18 May 2009 13:04:27 +0300
Message-ID: <225000070905180304u49e9a50btcc0f8935368afc03@mail.gmail.com>
Subject: [gentoo-dev] blocking mixed versions of split QT libraries
From: Alex Alexander <alex.alexander@gmail.com>
To: Gentoo-ML-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Archives-Salt: 716a2389-71da-4fe1-ab0e-2588c1e12bed
X-Archives-Hash: 61c9eff7ebcd0af2fc53e61241370cf4

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