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 1Es9Ee-0004Hv-1p for garchives@archives.gentoo.org; Fri, 30 Dec 2005 01:39:12 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBU1c5wP001542; Fri, 30 Dec 2005 01:38:05 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 jBU1YYtu024694 for ; Fri, 30 Dec 2005 01:34:35 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 1Es9AA-0001aj-JU for gentoo-dev@lists.gentoo.org; Fri, 30 Dec 2005 01:34:34 +0000 Received: by opteron246.suzuki-stubbs.home (Postfix, from userid 1000) id 2ACE5201B78; Fri, 30 Dec 2005 10:35:42 +0900 (JST) From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Multiple Repo Support Date: Fri, 30 Dec 2005 10:35:41 +0900 User-Agent: KMail/1.9 References: <43A235AD.6030604@leetworks.com> <20051227190619.3c824d0d@snowdrop.home> <1135874128.2170.6.camel@Darkmere.darkmere> In-Reply-To: <1135874128.2170.6.camel@Darkmere.darkmere> 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: <200512301035.41814.jstubbs@gentoo.org> X-Archives-Salt: 6762ca76-7343-440e-8d82-8e863f6416ee X-Archives-Hash: 53801200811ee7014de0b0f27b595ecd On Friday 30 December 2005 01:35, Spider (DmD Lj) wrote: > On Tue, 2005-12-27 at 19:06 +0000, Ciaran McCreesh wrote: > > On Tue, 27 Dec 2005 19:53:14 +0100 Carsten Lohrke > > > > wrote: > > | On Tuesday 27 December 2005 18:59, Ciaran McCreesh wrote: > > | > Nnnope. If you modify an eclass it forces a cache regen for packages > > | > using said eclass (except possibly if you're using an overlay, but > > | > that's a separate issue...). > > | > > | You're trying to solve something which is already solved, but this > > | has nothing to do with our problem. The question is not listen the > > | possible valid KDE versions or a change of the eclass, but the need > > | to know actual used KDE version. You'd need to call e.g. kde-config > > | to get it. And this breaks caching. > > > > So you RDEPEND upon the version of KDE against which you were built, > > and use the || ( ) flattening feature that's already been proposed. > > Thats actually viable. For -installed- ebuilds, we simply unpack all > RDEPEND logic, remove all use flags ( stored, but the use logic is > removed from the RDEPEND since its already resolved, doesn't need to be > there. The binary is static already ) > > Then check vs. the installed SLOT of all RDEPEND packages, and lock our > current deptree to the package of that SLOT... I suggested this last Tuesday.. > I can smell sooo much breakage from this solution. Even though it could > work : ) I'm not sure to interpret this as "yet another snide remark" or not so I'll give you the benefit of the doubt and assume you're referring to sets of ebuilds that require several slots. Before implementing the above, the tree will be checked for any cases where the above idea will fail. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list