From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 310451393E9 for ; Sat, 26 Jul 2014 08:30:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73BB1E0D16; Sat, 26 Jul 2014 08:30:23 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8D3E4E0CB3 for ; Sat, 26 Jul 2014 08:30:22 +0000 (UTC) Received: from [192.168.1.223] (113.139.217.87.dynamic.jazztel.es [87.217.139.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id A30B333F7D6 for ; Sat, 26 Jul 2014 08:30:20 +0000 (UTC) Message-ID: <1406363417.20388.30.camel@gentoo.org> Subject: Re: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined From: Pacho Ramos To: gentoo-dev@lists.gentoo.org Date: Sat, 26 Jul 2014 10:30:17 +0200 In-Reply-To: References: <53D2A6C8.9060900@gentoo.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.4 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 Content-Transfer-Encoding: 8bit X-Archives-Salt: 29af3981-0d25-4425-b2e4-ee99ce12efd4 X-Archives-Hash: a4ca8b068dda112b6b66361e7252365f El sáb, 26-07-2014 a las 08:05 +0000, Duncan escribió: > Ian Stakenvicius posted on Fri, 25 Jul 2014 14:49:44 -0400 as excerpted: > > > Hey all.. So, putting aside for now how much of a mess this would be to > > implement in the virtuals' ebuilds themselves, what do people think of > > changing the virtuals so that they contain an entry in IUSE for each > > provider that can satisfy it? > > > > The idea here is that the package satisfying a virtual could be > > optionally explicitly-chosen through package.use (or USE= in make.conf, > > perhaps) instead of having an entry in @world, that way if nothing > > depends on the virtual then it and the provider can be - --depclean'ed > > from the system. The idea is specifically NOT to have rdeps depend on > > these flags, that would undermine the whole purpose of the virtual; it > > would just be for end-users to set if they so chose. > > > > This may also help with getting portage to peg a virtual's provider to a > > specific package instead of constantly trying to switch from one to > > another, ie, how systemd kept getting pulled in, in relation to the > > upower virtual. > > What about handling each such virtual_USE as a USE_EXPAND? VIRTUAL_* as > reserved-namespace USE_EXPAND would give us full backward compatibility > along with an immediately identifiable namespace and virtually (heh) no > possibility of confusion with other configuration. > > Continuing with the earlier virtual/krb5 example, we'd have VIRTUAL_KRB5, > with possible settings in make.conf of: > > VIRTUAL_KRB5=mit-krb5 > VIRTUAL_KRB5=heimdal > > Virtually no possibility of confusion with normal USE flags, and the > matching virtual would be immediately identifiable, so no possibility of > getting confused on what it applies to, either. > I would also prefer to use USE_EXPAND to not mix normal USEs with virtuals... but I would go with using the same "VIRTUAL" variable for all virtuals, otherwise people will end up having dozens of VIRTUAL_ statements in make.conf (one per virtual package)