| 1 |
On Sun, Sep 20, 2015 at 9:27 AM, Manuel Rüger <mrueg@g.o> wrote: |
| 2 |
> On 19.09.2015 23:04, hasufell wrote: |
| 3 |
>> Friends, |
| 4 |
>> |
| 5 |
>> I think it is time to import LibreSSL[0]. There are not many packages |
| 6 |
>> left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby). |
| 7 |
>> |
| 8 |
>> My idea would be: |
| 9 |
>> |
| 10 |
>> 1. import "dev-libs/libressl" (this will block dev-libs/openssl) and |
| 11 |
>> introduce the global USE flag "libressl" with the following description: |
| 12 |
>> """ |
| 13 |
>> libressl - Use dev-libs/libressl as SSL provider (might need ssl USE |
| 14 |
>> flag), packages should not depend on this USE flag |
| 15 |
>> """ |
| 16 |
>> |
| 17 |
> |
| 18 |
> Devmanual says to discuss global useflags here before introducing them. |
| 19 |
> IMO merely announcing them is not enough. See |
| 20 |
> 288d8cd90fca12fafd021d86837851d8cb5c6efe. |
| 21 |
> |
| 22 |
|
| 23 |
++ |
| 24 |
|
| 25 |
I'm not hostile to the proposed plan, but you should at least allow a |
| 26 |
few days for things to settle down if we're not talking about security |
| 27 |
patches/etc. |
| 28 |
|
| 29 |
This isn't directed at anybody in particular, but I've been noticing a |
| 30 |
bit of a recent trend towards wanting to discuss a change at all == |
| 31 |
bikeshedding for years -> time to pout and threaten to walk out. It |
| 32 |
isn't really helpful. Gentoo is a fairly large project - this isn't |
| 33 |
some little community of 5 developers who chat at the bar and then go |
| 34 |
write their code. |
| 35 |
|
| 36 |
Discussing change serves many purposes: |
| 37 |
1. It provides notice of the change. |
| 38 |
2. It is possible that others will notice something the authors missed. |
| 39 |
3. It provides an opportunity for education. The way junior |
| 40 |
contributors become senior contributors is by interacting with those |
| 41 |
doing changes. That might mean making well-intentioned suggestions |
| 42 |
that don't work. |
| 43 |
|
| 44 |
SSL is pretty important, and over time I could see this becoming |
| 45 |
bigger than kerberos/ffmpeg/etc. It makes sense to at least give this |
| 46 |
change some thought. My concern with holding it up is that we don't |
| 47 |
actually have a practical alternative that we can implement today, at |
| 48 |
least not that I'm aware of. So, I'm more inclined to just let this |
| 49 |
move forward and let somebody with a grandiose plan for managing |
| 50 |
symbol collisions/etc to demonstrate it before holding everything else |
| 51 |
up. But, if people have plans that work in either the short- or |
| 52 |
long-term please speak up. |
| 53 |
|
| 54 |
-- |
| 55 |
Rich |
Archives