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 976C013877A for ; Sat, 26 Jul 2014 08:58:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4F0A5E0D47; Sat, 26 Jul 2014 08:58:42 +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 4959CE0CE9 for ; Sat, 26 Jul 2014 08:58:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8E30C33FF9A for ; Sat, 26 Jul 2014 08:58:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5.5 tests=[AWL=-0.801, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYNozc2eDDci for ; Sat, 26 Jul 2014 08:58:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id CCC2133FB3E for ; Sat, 26 Jul 2014 08:58:34 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XAxoF-0007b8-UH for gentoo-dev@gentoo.org; Sat, 26 Jul 2014 10:58:32 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Jul 2014 10:58:31 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 26 Jul 2014 10:58:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined Date: Sat, 26 Jul 2014 08:58:15 +0000 (UTC) Message-ID: References: <53D2A6C8.9060900@gentoo.org> 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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: 090c7443-b454-4e5d-bfda-d28772a07a6a X-Archives-Hash: 80f6e8e11191d5cdddc61fb88d8290f1 Duncan posted on Sat, 26 Jul 2014 08:05:32 +0000 as excerpted: > 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. > > What about handling each such virtual_USE as a USE_EXPAND? > [Example] VIRTUAL_KRB5 Hmm, thinking toward implementation, what about a virtual.eclass, inherited by virtuals? It could even have a declarative interface, such that from virtual/krb5-0.ebuild (I've left out the minversion and multilib-usedep stuff here as the example above did as well, but it could be passed too)... inherit virtual VIRTUAL_EXCLUSIVE="app-crypt/mit-krb5 app-crypt/heimdal" ... would setup most of the basics for an exclusive virtual, including the VIRTUAL_KRB5 USE_EXPAND name (based on $PN), the two providers and rdepends, the fact that they're exclusive and thus a default pkg_pretend or required_use, etc. In for instance virtual/editors, this could be used in place of its current RDEPEND: VIRTUAL_MULTI=" app-editors/nano app-editors/dav app-editors/e3 ... mail-client/alpine[-onlyalpine] sys-apps/ed " With an eclass, the default pkg_pretend for exclusive-virtuals would be standardized, standardizing the error message and explanation for it as well, giving it a chance to be a bit more informative than unstandardized one-offs might tend to be. Of course the same eclass idea could be used with simple USE flags as well, but I prefer the USE_EXPANDs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman