| 1 |
On Sun, Sep 20, 2015 at 7:14 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> On 09/20/2015 08:07 AM, Andrew Savchenko wrote: |
| 3 |
>> Greetings, |
| 4 |
>> |
| 5 |
>> On Sat, 19 Sep 2015 23:04:14 +0200 hasufell wrote: |
| 6 |
>>> Friends, |
| 7 |
>>> |
| 8 |
>>> I think it is time to import LibreSSL[0]. There are not many packages |
| 9 |
>>> left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby). |
| 10 |
>>> |
| 11 |
>>> My idea would be: |
| 12 |
>>> |
| 13 |
>>> 1. import "dev-libs/libressl" (this will block dev-libs/openssl) and |
| 14 |
>>> introduce the global USE flag "libressl" with the following description: |
| 15 |
>> |
| 16 |
>> Please try to avoid such block, e.g. install libressl to a separate |
| 17 |
>> location. |
| 18 |
> |
| 19 |
> No. I'm not going to hack downstream. |
| 20 |
> |
| 21 |
|
| 22 |
I don't think that it is the responsibility of the libressl maintainer |
| 23 |
to actually get other packages to use libressl - though they should |
| 24 |
document how it is done to facilitate this. |
| 25 |
|
| 26 |
However, if your point is that you want to be able to use libressl |
| 27 |
yourself as a drop-in replacement and this doesn't work if none of the |
| 28 |
other packages you use actually build against it when you move it, |
| 29 |
that is a fair point. |
| 30 |
|
| 31 |
I do think this is a good topic for discussion, however. It seems |
| 32 |
like forks that keep the original namespace is all the rage these days |
| 33 |
(kerberos, ffmpeg, openssl, mysql, etc). |
| 34 |
|
| 35 |
You've been a proponent of something like nixos for a while, and I'd |
| 36 |
think that this is exactly the sort of approach they take. They don't |
| 37 |
even keep the same namespace for a minor update of the same library. |
| 38 |
Of course, they have designed their build systems with this in mind, |
| 39 |
and perhaps this is a direction we need to evolve in as this sort of |
| 40 |
thing is coming up more and more. |
| 41 |
|
| 42 |
-- |
| 43 |
Rich |
Archives