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