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 1QDcrV-0000XZ-54 for garchives@archives.gentoo.org; Sat, 23 Apr 2011 13:27:01 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 60CEF1C024; Sat, 23 Apr 2011 13:26:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3FD281C015 for ; Sat, 23 Apr 2011 13:26:26 +0000 (UTC) Received: from [192.168.1.101] (hnvr-4d07906c.pool.mediaWays.net [77.7.144.108]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chithanh) by smtp.gentoo.org (Postfix) with ESMTPSA id 6433C1B4015 for ; Sat, 23 Apr 2011 13:26:25 +0000 (UTC) Message-ID: <4DB2D362.4020206@gentoo.org> Date: Sat, 23 Apr 2011 15:25:54 +0200 From: =?UTF-8?B?Q2jDrS1UaGFuaCBDaHJpc3RvcGhlciBOZ3V54buFbg==?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.18) Gecko/20110403 Gentoo/2.0.13 SeaMonkey/2.0.13 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] reconciling new-style virtuals with overlays, was: RDEPENDing on packages from overlays? References: <4DB26C3C.8090602@gentoo.org> <4DB2A9CD.7010708@gentoo.org> <4DB2B4EC.3070901@gentoo.org> In-Reply-To: <4DB2B4EC.3070901@gentoo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: 1b5a898c5dfe83153feb04c3e24ca437 Zac Medico schrieb: >> Would it make sense to do the following: >> (1) make all new-style virtuals additionally depend on an old-style >> virtual (a new category might be appropriate) >> (2) ebuilds in overlays can PROVIDE the old-style virtual >> > It seems like new-style virtual would be introducing complexity without > adding any value here. Why not just use a pure old-style virtual? > The idea is that code for old-style virtuals can be removed from the package manager (which seems to be one of the goals of getting rid of old-style virtuals). >> (3) in a future EAPI, package managers are allowed to ignore the >> old-style virtual dependency for packages which are not already installed >> > I'm not sure what you mean here. In || dependencies, it's normal to > ignore choices that are masked or unavailable, so I'm not sure that > you're suggesting anything different from the existing || behavior. > Indeed, the old-style virtual will be a non-existing package in the case of a package manager which doesn't support them. >> If directly including installed old-style virtual packages in the >> dependency calculations is not feasible, (3) could be implemented >> through modifying package.provided like it is already done for >> package.{keywords,mask,use} after profile/ updates >> > Again, I'm not sure that I understand the point of this. Since || > dependencies already ignore unavailable or masked choices, why would > package.provided be needed? > Because the package manager might not know about old-style virtuals during dependency calculation. Regards, Chi-Thanh Christopher Nguyen