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 ) id 1M5zz1-00049d-LT for garchives@archives.gentoo.org; Mon, 18 May 2009 10:22:12 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BF52DE01BC; Mon, 18 May 2009 10:22:10 +0000 (UTC) Received: from mailfilter7.ihug.co.nz (mailfilter7.ihug.co.nz [203.109.136.7]) by pigeon.gentoo.org (Postfix) with ESMTP id 51253E01BC for ; Mon, 18 May 2009 10:22:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYCAGvTEEp2XJyM/2dsb2JhbAAIzx6EAQWFag X-IronPort-AV: E=Sophos;i="4.41,208,1241352000"; d="scan'208";a="185736497" Received: from 118-92-156-140.dsl.dyn.ihug.co.nz (HELO [192.168.0.3]) ([118.92.156.140]) by smtp.mailfilter1.ihug.co.nz with ESMTP; 18 May 2009 22:22:06 +1200 Message-ID: <4A1136D4.9010708@gentoo.org> Date: Mon, 18 May 2009 22:22:12 +1200 From: Alistair Bush User-Agent: Thunderbird 2.0.0.21 (X11/20090325) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] blocking mixed versions of split QT libraries References: <225000070905180304u49e9a50btcc0f8935368afc03@mail.gmail.com> In-Reply-To: <225000070905180304u49e9a50btcc0f8935368afc03@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: url= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3b527c6f-b9bd-4f84-b601-93a3a9508b85 X-Archives-Hash: 1708f4c48c4b8384ecd070103ae6f8c0 Alex Alexander wrote: > 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. >From what I understand you are utilizing portages ability to automagically resolve blockers when all blockers will be resolved within the current command. Agree?? or is it the fact that you are doing !>x11-libs/qt-assistant-${PV}-r9999 that is causing the paludis problem? I would suggest that you just tell paludis users to use --dl-blocks discard when updating qt. After looking at the eclass im not sure whether it will work or not. im assuming that discarding blocks will just ignore everything, but I haven't tested it so can't be sure. > > 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? I don't believe so, not within current ways of declaring dependencies. > 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"? I say we should be stopping them from happening. > > 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. > And I would agree with the hackish comment. > thanks Good work btw. Alistair.