From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-65957-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A46101381FA for <garchives@archives.gentoo.org>; Fri, 30 May 2014 02:21:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 22926E09E2; Fri, 30 May 2014 02:21:13 +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 0A246E09D6 for <gentoo-dev@lists.gentoo.org>; Fri, 30 May 2014 02:21:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 064ED33FC4C for <gentoo-dev@lists.gentoo.org>; Fri, 30 May 2014 02:21:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5.5 tests=[AWL=-0.843, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 J1ynHm26XtnE for <gentoo-dev@lists.gentoo.org>; Fri, 30 May 2014 02:21:04 +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 005DE33FC95 for <gentoo-dev@gentoo.org>; Fri, 30 May 2014 02:21:00 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <lnx-gentoo-dev@m.gmane.org>) id 1WqCRC-0005VI-Uz for gentoo-dev@gentoo.org; Fri, 30 May 2014 04:20:54 +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 <gentoo-dev@gentoo.org>; Fri, 30 May 2014 04:20:54 +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 <gentoo-dev@gentoo.org>; Fri, 30 May 2014 04:20:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Creating a USE_EXPAND for ssl providers Date: Fri, 30 May 2014 02:20:43 +0000 (UTC) Message-ID: <pan$e992$fe46ea16$4b74f564$84544af1@cox.net> References: <53877169.3010800@gentoo.org> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> 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 2ae6aff /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 0ea3f7d5-7292-4fa4-8fc7-aad542e4c182 X-Archives-Hash: fff91a110c1f048ab90873a926e6a9a6 Anthony G. Basile posted on Thu, 29 May 2014 13:42:01 -0400 as excerpted: > With the number of ssl providers growing, like libressl, and with issues > like bug #510974, I think its time we consider making this a uniform way > of dealing with ssl providers in gentoo. We would proceed something > like this: > > 1. Introduce a new USE_EXPAND called SSL which mirrors CURL_SSL --- > becuase CURL_SSL is too provincial a name. > > 2. migrate curl and all its dependencies to the SSL use expand. > > 3. Migrate over all consumers of ssl to the new SSL use expand system. > > What do people think? What about an ssl.eclass to handle it? Obviously Peter's concern about packages that only support some of the options would need to be taken into account, with some sort of variable, say SSL_SUPPORTED, that would be set before eclass inheritance. Then the eclass could formalize the general dependency logic and expose variables of its own that could in turn be used to set package specific options. Or is package handling too individualized for an eclass to work well, even with a mechanism to tell the eclass which ssl providers were supported and further mechanisms to allow package specific logic where required? -- 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