From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1ErEU1-0007PN-HU for garchives@archives.gentoo.org; Tue, 27 Dec 2005 13:03:17 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBRD0vvZ018303; Tue, 27 Dec 2005 13:00:57 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBRCvjhg017743 for ; Tue, 27 Dec 2005 12:57:45 GMT Received: from zb101200.ppp.dion.ne.jp ([219.125.101.200] helo=opteron246.suzuki-stubbs.home) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1ErEQ8-0001S5-0x for gentoo-dev@lists.gentoo.org; Tue, 27 Dec 2005 12:59:16 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id 4DF2A201AC8; Tue, 27 Dec 2005 22:00:19 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Multiple Repo Support Date: Tue, 27 Dec 2005 22:00:18 +0900 User-Agent: KMail/1.9 References: <43A235AD.6030604@leetworks.com> <200512270354.47661.carlo@gentoo.org> <20051227030816.GL5809@nightcrawler.e-centre.net> In-Reply-To: <20051227030816.GL5809@nightcrawler.e-centre.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512272200.19011.jstubbs@gentoo.org> X-Archives-Salt: b0b77bcb-3e04-43f8-9a36-73998432ba42 X-Archives-Hash: e6a1805b7c2f88d23bb2f721352a63a8 On Tuesday 27 December 2005 12:08, Brian Harring wrote: > On Tue, Dec 27, 2005 at 03:54:38AM +0100, Carsten Lohrke wrote: > > On Tuesday 27 December 2005 03:40, Brian Harring wrote: > > > The version of digikam being merged requires slot=3.5- it should be > > > depending on libk* slot=3.5, also, no? > > > > No! It (and also its dependencies) can be built against each 3.x slot. > > > > > As long as the information is represented dependency wise, portage > > > should be able to handle it fine. Just need to have that info there. > > > > It can't be handled dependency wise, because what is interesting is > > against which KDE version the relevant ebuilds are actually installed. > > So note the comment in the email you are responding to about locking > down the used dep/rdeps for an install. > > Via that, could lock down the slot it was compiled against. Bit more > to it then that, but the concerns your raising *again* are not > use/slot based, your pointing at other portage faults (thus please > seperate those concerns from use/slot). I may be missing something, but I can't see how this will resolve Carsten's issue. From what I can tell, the ebuilds would be laid out something like: digikam:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 ) libkipi libkexif" libkipi:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 )" libkexif:DEPEND="|| ( kdelibs:3.5 kdelibs:3.4 )" If all three of those packages were first built against kdelibs:3.4 and then kdelibs:3.5 became available then rebuilding any one of them without rebuilding the others will break digikam. I can't see how it's directly represented in the metadata unless you want to overload the meaning of SLOT. If overloading, dependencies would be flattened (meaning "|| ( kdelibs:3.5 kdelibs:3.4 )" would have became "kdelibs:3.4" for the original install) within the installed package database but there's also there's the implication that only one slot of a package be allowed in a connected set of nodes. Is that what you're getting at? -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list