From: "Anthony G. Basile" <blueness@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Re: ssl vs openssl vs libressl vs gnutls USE flag foo
Date: Wed, 28 Oct 2015 07:23:05 -0400 [thread overview]
Message-ID: <5630B019.5070805@gentoo.org> (raw)
In-Reply-To: <5630AE93.2030303@gentoo.org>
On 10/28/15 7:16 AM, hasufell wrote:
> On 10/28/2015 07:23 AM, Ryan Hill wrote:
>> Agreed. If there's one choice then "ssl" should be used. openssl/libressl/etc
>> should really be considered sub-flags of ssl.
This is what I did with curl. USE=ssl means one and exactly one ssl
provider must be specified. I suggested making it a model gentoo wide,
but there were criticisms, I forget what, but the made sense to me at
teh time.
>>
>> I really wish we had some way of specifying this to make things clearer to the
>> user, so they could see exactly how these flags interact with each other.
>> Something like (emerge -pv):
>>
> The problem here is that we introduced REQUIRED_USE foo for these cases
> which is again highly ambigous instead of making the PM aware that this
> is an actual sub-USE flag.
A properly designed sub-USE flag would be useful here and clearly better
than our REQUIRED_USE. I think REQUIRED_USE is fine for heterogeneous
cases, but not when you have something like curl where you can either
turn ssl on or off. If it is off, nothing more needs to be specified,
if it is on, then you must further specify one and exactly one ssl provider.
>
> This is outside of the scope of this thread, but there are already
> distros that have fixed this:
> 1. NixOS [0] with truly declarative configuration format, e.g. something
> like:
> packages.ssl.provider = openssl;
>
> or somesuch (just an example)
>
> 2. Exherbo partly [1] with providers syntax:
> */* providers: -openssl libressl
>
> and the exheres would then do something like:
> DEPENDENCIES="
> build+run:
> providers:openssl? ( dev-libs/openssl:0 )
> providers:libressl? ( dev-libs/libressl )
> "
>
> which is a lot cleaner than USE_EXPAND + REQUIRED_USE, which still can
> have arbitrary meanings.
>
> But NIH will prevent us from learning here I guess.
>
>
> [0] https://nixos.org/nixos/manual/
> [1] http://exherbo.org/docs/eapi/providers-and-virtuals.html
>
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
next prev parent reply other threads:[~2015-10-28 11:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 2:06 [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo hasufell
2015-10-28 2:46 ` Rich Freeman
2015-10-28 4:35 ` Gordon Pettey
2015-10-28 6:23 ` [gentoo-dev] " Ryan Hill
2015-10-28 11:16 ` hasufell
2015-10-28 11:23 ` Anthony G. Basile [this message]
2015-10-28 11:30 ` hasufell
2015-10-28 15:11 ` Anthony G. Basile
2015-10-28 11:32 ` Kristian Fiskerstrand
2015-10-28 13:51 ` Rich Freeman
2015-10-28 11:20 ` Kristian Fiskerstrand
2015-10-28 11:24 ` hasufell
2015-10-30 17:55 ` [gentoo-dev] " Michał Górny
2015-10-30 19:35 ` hasufell
2015-10-30 21:16 ` Anthony G. Basile
2015-10-30 22:25 ` Rich Freeman
2015-10-30 23:10 ` Michał Górny
2015-10-30 22:40 ` hasufell
2015-10-30 22:56 ` Michał Górny
2015-10-30 23:13 ` hasufell
2015-10-30 23:06 ` Luis Ressel
2015-10-30 20:07 ` Rich Freeman
2015-10-28 8:36 ` Alexis Ballier
2015-10-28 11:21 ` hasufell
2015-10-29 13:27 ` Chí-Thanh Christopher Nguyễn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5630B019.5070805@gentoo.org \
--to=blueness@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox