The summary says it all...kde-base/arts-3.5.4 depends on qt >= 3 && qt < 4.
Yes. And... ???
sorry, I guess I wasn't very clear on this :) ... The current dependancy in the ebuild specifies "$(qt_min_version 3.3)"...however the < 4.0 part is not specified. When emergeing on a fresh 2006.0 Stage 3 system, it fails because when emerging arts, the qt 4.0 slot is satisfied, but the qt3 slot is not satisfied.
I need more information. $(qt_min_version 3.3) is a function in the qt3.eclass that specifically forces version 3. Verison 4 shouldn't have any impact.
perhaps qt4 has no impact, but portage doesn't recognize there's a dependancy on the qt3 slot being satisfied.
What does emerge -p arts show? I assume you don't already have Qt3 installed? Are you sure you have emerge synced properly and don't have an overlay? Your emerge info would be helpful.
(In reply to comment #3) > I need more information. > > $(qt_min_version 3.3) is a function in the qt3.eclass that specifically forces > version 3. Verison 4 shouldn't have any impact. > caleb, please read (your own?) notes in qt3.eclass. <snip> # Currently, the ebuild assumes that a minimum version of Qt3 is NOT satisfied by Qt4 </snip> The current method is broken w/ QT slots. Also - you are using identically named functions in qt{3,4} eclass - why not use qt3_min_version() for QT3 and qt4_min_version() for QT4 (and require explicit inherit of those eclasses, instead of relying upon what gets inherited via what kde.eclass inherits via kde-functions.eclass (or similar unreliable chain?) And what happens if some ebuild happens to inherit both qt eclasses, which qt_min_version will be used?
The eclasses are simply designe to work aroudn this portage limitation: DEPEND=">=qt-3.0 <qt-4.0" Which doesn't work because of the slotting. You have to give me more information to explain to me how this is broken. The qt3 ebuild simply expands out Qt versions with an =. So, qt_min_version 3.3 equates to: DEPEND=( || ( =x11-libs/qt-3.3.6-r1 =x11-libs/qt-3.3.6 =x11-libs/qt-3.3.5 ... ) ) Meaning that it is forcing a Qt3 version to be in the depend structure. So, Qt4 is NOT satisfied by this. But you don't need Qt4 for arts, so I don't understand where the problem lies.
Note: I'm not trying to be difficult here. I just don't understand yet what the problem is.
(In reply to comment #7) > qt3 ebuild simply expands out Qt versions with an =. So, qt_min_version 3.3 > equates to: How do you ensure which one qt_min_version() gets used when USE set inherit qt3 qt4 in an ebuild? Or, both will get used? Now imagine this all happens in huge chain of ebuilds, like on a fresh install. > But you don't need Qt4 for arts, so I don't understand where the problem lies. Well, apparently the eclass hack fails for some people. This is not the first one, see Bug 135707. Again might have something to do w/ the fact that qt_min_version is used in both eclasses. A sample ebuild to show how is this broken: <snip> # Copyright 1999-2006 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ inherit qt4 qt3 DESCRIPTION="This is a QT eclass test ebuild" HOMEPAGE="http://foo.bar.com/" SRC_URI="" LICENSE="GPL-2" SLOT="0" DEPEND="$(qt_min_version 4.0)" RDEPEND="${DEPEND}" KEYWORDS="x86" </snip> # emerge -pv test These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-misc/test-0 0 kB [1] Total size of downloads: 0 kB Portage overlays: [1] /usr/local/portage [2] /mnt/nfs/overlays/vmware # emerge -pv =qt-4* These are the packages that would be merged, in order: Calculating dependencies !!! All ebuilds that could satisfy "=qt-4*" have been masked. !!! One of the following masked packages is required to complete your request: - x11-libs/qt-4.2.0_pre1 (masked by: package.mask, missing keyword) - x11-libs/qt-4.1.4 (masked by: package.mask) - x11-libs/qt-4.1.2 (masked by: package.mask) - x11-libs/qt-4.1.3 (masked by: package.mask) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. Now, if you change the ebuild to have "inherit qt3 qt4" instead, you'll get the expected result (can't emerge b/c I've package.masked QT4)
> How do you ensure which one qt_min_version() gets used when USE set inherit qt3 > qt4 in an ebuild? Or, both will get used? Now imagine this all happens in huge > chain of ebuilds, like on a fresh install. Hadn't thought of that when I wrote it. I'll probably make it fail. It was never designed to have both inherited at the same time. > Well, apparently the eclass hack fails for some people. This is not the first > one, see Bug 135707. Again might have something to do w/ the fact that > qt_min_version is used in both eclasses. Yep, I realize this. But the point is that it shouldn't be failing, so I want to understand what the reporter is doing that would be causing it to fail. As is, the qt3 ebuild forces a qt3 version, so when installing arts qt3 dep should be met.
> Hadn't thought of that when I wrote it. I'll probably make it fail. It was > never designed to have both inherited at the same time. Hmmm, not sure about this. I'm afraid of cases like "inherit qt4 kde" (no, I didn't check for actual ebuilds that use it, but still). Anyway, I've grepped the whole tree for stuff using $(qt_min_version 4.x) and it's just two ebuilds: /usr/portage/app-office/texmaker/texmaker-1.30.ebuild: $(qt_min_version 4.1)" /usr/portage/games-kids/cubetest/cubetest-0.9.4.ebuild:DEPEND="$(qt_min_version 4)" If you want to verify, this is what I used: <snip> find /usr/portage -name '*.eclass' -o -name '*.ebuild' | xargs grep "qt_min_version 4" | tee qt4_min_version.log >/dev/null 2>&1 </snip> So, it should be fairly painless to rename that function to qt4_min_version() and fix those two ebuilds.
Ok, fixed the qt4 eclass as noted in previous notes. I am unable to reproduce the issue at hand here, so unless you can provide more information as requested I'm closing as a WORKSFORME.
